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Headquarters,  United  States  Air  Forces  Europe  (HQ  USAFE)  site  of  the  Air  Force 
Integrated  Readiness  Measurement  System  (AFIRMS),  (Contract  No.  F49642-83-C-0022), 
is  written  to  fulfill  the  following  objectives: 

a.  To  provide  a  detailed  definition  of  the  HQ  USAFE  subsystem  functions. 

b.  To  communicate  specification  details  of  the  subsystem  functional  requirements. 

c.  To  define  in  detail  the  interfaces  with  other  systems  and  subsystems  and  the 
facilities  to  be  utilized  for  accomplishing  these  interfaces. 

The  subsystem  specification  also  contains,  as  appendices,  the  specifications  for  each 
of  the  products  required  for  subsystem  implementation. 

This  subsystem  specification  applies  to  HQ  USAFE  and  only  broadly  relates  to  the 
other  major  commands  (MAJCOMs).  Each  MAJCOM's  requirements  are  thoroughly 
specified  during  the  in-depth  analysis  that  precedes  its  implementation. 

1.2  Introduction  to  AFIRMS.  This  section  provides  a  brief  introduction  to  the  AFIRMS. 

A  more  complete  description  is  provided  in  the  AFIRMS  Functional  Description. 


1.2.1  AFIRMS  Synopsis. 


1.2. 1.1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to  perform 
tasked  missions  based  on  the  availability  of  specific  resources. 


The  conceptual  requirements  for  AFIRMS  are  two-fold: 

(1)  Assessment  of  combat  capability  against  specific  tasking.  The  user  can 
select  any  planned  or  ad  hoc  tasking  against  which  to  make  capability 
assessments,  i.e.,  VI  ar  Mobilization  Plan  (MMP),  Operation  Plan  (OPIan), 
Fragmentary  Order,  Air  Tasking  Order  (ATO),  Contingency  Plan,  etc. 
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(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 

AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This  tool  permits 
comparison  of  readiness  and  sustainability  by  fiscal  year  and  can 
therefore  highlight  the  impact  of  appropriation  changes.  Thus,  changes  in 
funding  are  related  to  changes  in  force  readiness  and  sustainability.  Also, 
senior  Air  Force  decision  makers  are  supported  during  budget 
deliberations  and  Air  Force  budget  allocations. 

b.  AFIRMS  implementation  has  two  key  concepts: 

(1)  Integrated  approach  to  tasking  based  capability  assessments.  AFIRMS  has 
two  integrative  dimensions.  First,  all  applicable  resources  and  their  usage 
interactions  of  such  resources  are  considered.  For  example,  in  sortie 
capability  assessment,  AFIRMS  evaluates  capability  in  terms  of  all  four 
essential  resource  types  (aircrew,  aircraft,  munitions,  fuel),  their 
interdependencies,  and  their  generative  components  (such  as  spares  for 
aircraft,  training  qualifications  for  aircrew,  load  crews  for  munitions,  and 
hot  pits  for  fuel).  Second,  other  automated  systems  (such  as  the  Combat 
Supplies  Management  System  (CSMS),  Combat  Fuels  Management  System 
(CFMS),  Weapon  System  Management  Information  System  (WSMIS),  etc.) 
outputs  are  integrated  into  capability  assessment  calculations  through 
system  interfaces  between  those  systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than  the  data 
upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a  user  orientation 
toward  quality  assurance  of  source  data.  Unit  and  other  data  input  level 
users  are  provided  effective  tools  to  accomplish  their  daily  activities  and 
therefore  develop  a  vested  interest  in  AFJRM5  data  currency  and 
validity.  Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  vitality. 


1.2.1. 2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess  readiness 
capability: 

a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system,  tasking 
must  be  converted  into  a  standard  format  recognized  by  AFIRMS.  Tasking  is 
defined  in  AFIRMS  to  the  unit  level  and  may  consist  of  actual,  hypothetical, 
standard,  or  contingency  tasking.  Any  of  these  taskings  can  be  defined  within 
specified  WMP  or  OPlan  constraints,  at  the  option  of  the  user.  Likewise,  the 
tasking  may  be  defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures  that 
information  about  inventory  status  is  available  and  accurate.  Wherever 
possible,  this  data  is  obtained  by  interface  with  other  functional  systems.  As 
with  tasking,  resource  information  can  be  defined  for  actual,  hypothetical, 
standard,  or  contingency  situations,  either  present,  historic,  or  future. 


c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to 
perform  is  the  essential  function  of  AFIRMS.  The  tasking  and 
resource  data  are  processed  to  determine  how  much  of  the  specified 
tasking  can  be  accomplished  with  the  resources  available.  Ability  to 
perform  is  evaluated  in  terras  of  the  task  metric  (sorties , etc. )  and 
the  cost  metric  (dollars)  to  provide  readiness/sustainability  and 
dollars  to  readiness  assessments. 

d.  Aggregate,  Analyze  and  Present  Data.  Aggregation,  analysis  and 
resentation  ensure  the  proper  grouping  and  display  of  data  to  provide 
useful  information  at  the  unit,  major  command  and  HQ  USAF. 
Aggregation  refers  to  the  creation  of  a  composite  understanding  of 
capability  for  several  units. 


1.2.2  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describes 
AFIRMS.  A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document. 


a.  Functional  Description  (FD).  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

c.  Management  Plan.  The  Management  Plan  provides  the  top-level 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS.  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  Systems  Interface  Support  Plan. 

d.  System  Specification.  The  AFIRMS  System  Specification  adds  the 
design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems  (HQ  USAF,  HQ  USAFE  (MAJCOM),  and  Wing 
(unit))  and  assigns  functions  required  within  each  subsystem.  The 
system  specification  details  the  overall  architecture,  intersite 
interface  gateways,  processing  logic  flows  and  the  communications 
network  specifications. 

e.  Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 
specifications:  HQ  USAF,  HQ  USAFE  ( MAJCOM/numbered  Air  Force),  and 
the  Wing  (unit/squadron).  Subsystem  specifications  detail  the 

specific  design  and/or  performance  requirements  of  the  system  at  that 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functional  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 
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f. 


Database  Specifications.  There  are  three  AFIRMS  database 
specifications:  HQ  USAF,  HQ  USAFE  ( MAJCOM/numbered  Air  Force),  and 
Wing  (unit/squadron) .  These  specifications  describe  the  database 
architecture,  size  and  content,  as  well  as  logical  data  relationships 
for  the  functions  performed  at  each  of  the  AFIRMS  levels. 
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g.  Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes,  and 
groups  the  generic  types  of  data  used  in  AFIRMS.  It  aiso  defines  each  type  of 
AFIRMS  data  element  (attribute  class). 

h.  Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products  which 
implement  the  AFIRMS  functions  as  input  and  output  tools. 

i.  Transform  and  Model  Descriptions.  The  Transform  and  Model  Descriptions 
Document  defines  how  AFIRMS  calculates  the  output  data  from  the  input  data. 
Specific  algorithmic  calculations  are  provided.  Logical  groups  of  algorithms 
forming  AFIRMS  models  and  transforms  are  described. 

1.3  Project  References.  Accurate  assessment  of  force  readiness  and  sustainability  has 
been  a  constant  concern  of  Air  Force  commanders  and  their  staffs.  This  concern  has  been 
supported  by  an  intensified  DoD-wide  interest  in  capability.  In  response  to  this  Air  Force 
concern,  the  Directorate  of  Operations  and  Readiness  initiated  the  AFIRMS  Program. 
AFIRMS  has  been  under  development  through  a  learning  prototype  and  is  designed  to 
provide  Air  Force  commanders  with  a  complete,  timely,  and  accurate  assessment  of  their 
operational  readiness  and  sustainability.  In  performing  this  function,  AFIRMS  provides 
combat  capability  assessments  to  Air  Force  leaders  at  HQ  USAF,  major  command 
(MAJCOM),  and  wing  levels  of  command  to  aid  them  in  making  total  force  readiness 
decisions.  AFIRMS  also  supports  day-to-day  operations  and  crisis  management  as  well  as 
planning  and  programming  activities  at  all  command  levels. 

The  Program  Management  Office  (PMO)  responsible  for  contract  management  of  the 
AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  document  is  the  Data  Systems  Design 
Office  (DSDO/XO),  Gunter  Air  Force  Station  (AFS),  Alabama;  the  Office  of  Primary 
Responsibility  (OPR)  is  the  United  States  Air  Force  Readiness  Assessment  Group 
(AF/XOOIM).  Three  operational  centers  have  been  in  use  as  LPP  testbed  sites:  The 
Pentagon,  Washington,  D.C.;  HQ  U5AFE,  Ramstein  Air  Base  (AB),  Germany;  and,  the  52nd 
Tactical  Fighter  Wing  (TFW),  Spangdahlem  AB,  Germany. 

References  which  are  applicable  to  the  history  and  development  of  the  AFIRMS 
Program  are  listed  below  along  with  references  concerning  programming  and 
documentation  standards. 

a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 

31  May  1985.  (Unclassified) 
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AFIRMS  Evolutionary  Implementation  Plan,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 


AFIRMS  Functional  Description,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMb),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 

AFR  700-2,  Information  Systems  Planning,  26  October  1984.  (Unclassified) 

AFR  700-5,  Information  System  Requirements  Board,  9  November  1984. 
(Unclassified) 

AFR  205-16,  Automated  Data  Processing  (ADP)  Security  Policy,  Procedures, 
and  Responsibilities,  1  August  1984.  (Unclassified) 

AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (FOUO) 

DoD-STD-7935. 1,  Automated  Data  Systems  (ADS)  Documentation  Standards, 

24  April  1984.  (Unclassified) 


u.  JCS  Pub  1,  Department  of  Defense  Dictionary  of  Military  and 
Associated  Terms,  24  April  1984.  (Unclassified) 

v.  AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984. 
(Unclassified) 

w.  AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022 , 
13  February  1985  (FOUO) 

x.  AFR  300-4,  Voi.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (FOUO) 

y.  Sustainability  Assessment  Model  (formerly  CAC)  Functional 
Description,  Contract  No.  F33700-83-G-002005701,  8  April  1983. 
(Unclassified) 

z.  AFR  700-3,  Information  Systems  Requirements  Processing, 

30  November  1984.  (Unclassified) 

aa.  MIL-STD-480  Configuration  Control-Engineering  Changes,  Deviations, 
and  Waivers. 

bb.  MIL-STD-483  Configuration  Management  Practices  fox  Systems, 

Equipment,  Munitions,  and  Computer  Programs. 

*cc.  USAF  Operational  Major  Command  Functional  Area  Requirement  (FAR), 
SofTech,  Contract  No.  F49642-82-C-0045 ,  15  December  1982. 

(Unclassified) 

dd.  AFR  55-15,  Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status 
and  Identity  Report  (UNITREP),  RCS  :  HAF-XOO(  AR)7U2(  DD) ) , 

22  November  1982  .  (Unclassified) 

*ee.  USAFE  Annex  to  USAF  FAR,  SofTech,  Contract  No.  F49642-82-C-0045 , 

20  August  1982.  (Unclassified) 

*ff.  AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396 ,  14  March  1980. 
(Unclassified) 

gg.  AFIRMS  Data  Analysis,  SofTech,  15  February  1979.  (Unclassified) 

hh.  User's  View  of  AFIRMS,  SofTech,  1  November  1978.  (Unclassified) 

ii.  AFR  700-9,  Information  Systems  Standards,  15  March  1985. 

(Unclassified) 

jj.  AFM  11-1,  Vol.  1,  U.S.  Air  Force  Glossary  of  Standardized  Terms, 

2  January  1976.  (Unclassified) 


*  Material  contained  in  references  cc  and  ee  expands  on  that  found  in 
reference  ff. 
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kk.  AFIRMS  Data  Automation  Requirement  (DAR),  Final,  SofTech,  Contract 
No.  MDA-903-76-C-0396,  14  March  1980  .  (Unclassified) 

11.  JCS  Memorandum  of  Policy  #172,  1  June  1982  .  (Unclassified) 

mm.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  1. 

nn.  FIPS  PUB  15,  Section  1. 

oo.  Military  Aiflift  Command  (MAC)  AFIRMS  Requirements  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022,  30  September  1985.  (Unclassified) 

pp.  Analysis  of  Military  Airlift  Command  (MAC)  Capability  Assessment 

Metrics,  SofTech,  Contract  No.  F49642-83-C-0022 ,  30  September  1985. 
(Unclassified) 

qq .  Strategic  Air  Command,  (SAC)  AFIRMS  Requirements  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022 ,  30  September  1985.  (Unclassified) 

rr.  Analysis  of  Strategic  Air  Command  (SAC)  AFIRMS  Capability  Assessment 
Metrics,  SofTech,  Contract  No.  F49642-83-C-0022,  30  September  1985. 
(Unclassified) 
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1.4  Abbreviations  and  Acronyms. 


AB 

ADP 

ADPS 

AF 

AFIRMS 

AFR 

AFS 

ALC 

ANSI 

ASCII 

A  TO 

BPI 

BPS 

CAS 

CBU 

CFMS 

CN 

CNM 


Air  Base 

Automated  Data  Processing 
Automated  Data  Processing  System 
Air  Force 

Air  Force  Integrated  Readiness  Measurement  System 
Air  Force  Regulation 
Air  Force  Station 
Air  Logistics  Center 
American  National  Standards  Institute 
-  American  Standard  Code  for  Information  Exchange 
Air  Tasking  Order 
Bits  Per  Inch 
Bits  Per  Second 
Combat  Ammunition  System 
Cluster  Bomb  Unit 
Combat  Fuels  Management  System 
Central  Node 
Central  Node  Module 
CONPLAN  -  Concept  Plan 
CONUS  -  Continental  United  States 
Characters  Per  Inch 
Characters  Per  Line 
Characters  Per  Second 
Central  Processing  Unit 
Cyclical  Redundancy  Checking 
Cathode  Ray  Tube 

Combat  Supplies  Management  System 


CPI 

CPL 

CPS 

CPU 

CRC 

CRT 


CSMS 


DAR 


Data  Automation  Requirement 


DBMS 

DDN 

DoD 

DRD 

DSDO 

EA 

EIP 

EMSEC 

FA 

FAW 

FD 

FIPS  PUB  - 

FOUO 

FTP 

HOL 

HQU5AF  - 

HQ  USAFE  - 

IA  A 

I/O 

IP 

IPS 

ISO 

LED 

LPI 

LPM 

LPP 

MAC 


Database  Management  System 
Defense  Data  Network 
Department  of  Defense 
Data  Requirements  Document 
Data  Systems  Design  Office 
Economic  Analysis 
Evolutionary  Implementation  Plan 
Emanations  Security 
Functional  Area 
Functional  Area  Workstation 
Functional  Description 

Federal  Information  Processing  Standards  Publication 

For  Official  Use  Only 

File  Transfer  Protocol 

High  Order  Language 

Headquarters,  United  States  Air  Force 

Headquarters,  United  States  Air  Forces  Europe 

In  Accordance  With 

Input/Output 

Internet  Protocol 

Inches  Per  Second 

International  Standards  Organization 

Light-Emitting  Diode 

Lines  Per  Inch 

Lines  Per  Minute 

Learning  Prototype  Phase 

Military  Airlift  Command 


M  A  3COM 

- 

Major  Command 

MDS 

- 

Mission,  Design,  Series 

MICAP 

- 

Mission  Capable 

NATO 

- 

North  Atlantic  Treaty  Organization 

NBS 

- 

National  Bureau  of  Standards 

NSA 

- 

National  Security  Agency 

OCR 

- 

Optical  Character  Reader 

OPlan 

- 

Operation  Plan 

OPORD 

- 

Operation  Order 

OPR 

- 

Office  of  Primary  Responsibility 

PD 

- 

Product  Descriptions 

PMO 

- 

Program  Management  Office 

POL 

- 

Petroleum,  Oil,  and  Lubricants 

POM 

- 

Program  Objective  Memorandum 

PPL 

- 

Preferred  Products  List 

SCL 

- 

Standard  Conventional  Load 

SMTP 

- 

Simple  Mail  Transfer  Protocol 

TAF 

- 

Tactical  Air  Force 

TCP 

- 

Transmission  Control  Protocol 

TFW 

- 

Tactical  Fighter  Wing 

USAFE 

- 

United  States  Air  Forces  Europe 

WIN 

- 

W  W'MCCS  Intercomputer  Network 

W  M  P 

- 

War  Mobilization  Plan 

WSMIS 

- 

Weapon  System  Management  Information  System 

WWMCCS 

- 

World  Wide  Military  Command  and  Control  System 
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SECTION  2.  SUMMARY  OF  REQUIREMENTS 


AFIRMS  is  a  tasking  based  capability  assessment  system  that  assesses 
readiness  and  sustainability  by  applying  specific  tasking  (identified  to 
accomplish  the  assessments  desired)  against  selected  unit  and  theatre 
resources  through  the  use  of  automated  assessment  models.  As  a  decision 
support  tool,  it  provides  Air  Force  commanders  at  all  levels  with  the  ability 
to  assess  capability  to  meet  a  specific  tasking.  The  requirement  for  AFIRMS 
is  two-fold: 


a.  Assess  capability  against  any  tasking.  The  operator  of  the  system 
can  select  a  tasking  against  which  to  make  assessments,  i.e.,  War 
Mobilization  Plan  (WMP),  Operations  Plan  (OPlan),  what-if  plan,  and 
Air  Tasking  Order  (ATO).  AFIRMS  then  provides  a  capability 
assessment  against  that  scenario  in  a  mission  unit  of  measure. 

b.  Correlate  dollar  costs  to  readiness  assessment  impacts  of 
appropriations  by  fiscal  year.  The  capability  metric  transformed 
from  missions  to  dollars  for  assessments  from  this  budgetary 
perspective. 


The  worldwide  operational  AFIRMS  is  a  hierarchically  structured  system 
which  can  be  visualized  as  a  pyramid  of  distinct  operational  sites.  Each 
operational  site  performs  a  set  of  functions  which  are  distinct  from,  although 
similar  to,  other  sites  and  transmits  information  logically  upward  to  a  parent 
site.  There  are  three  basic  levels  within  the  AFIRMS  pyramid,  each  level 
being  considered  as  an  AFIRMS  subsystem.  The  highest  level  subsystem,  the 
apex  of  the  pyramid,  is  the  HQ  USAF  subsystem.  The  second  level  of  the 
pyramid  consists  of  the  MAJCOM  subsystems.  Each  Major  Command  contains  at 
least  one  AFIRMS  MAJCOM  subsystem;  one  for  the  MAJCOM  HQ,  and  one  for  each 
Numbered  Air  Force  (or  Air  Logistics  Center)  in  the  MAJCOM,  as  applicable. 

The  base  of  the  pyramid  is  composed  of  a  set  of  wing  subsystems.  Each  wing 
within  a  MAJCOM  contains  an  AFIRMS  wing  subsystem  which  is  connected  to  the 
parent  MAJCOM. 
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2.1  HQ  USAFE  Subsystem  Description.  The  HQ  USAFE  site  in  the  operational 
AFIRMS  is  one  of  several  mid-level  command  entities  in  the  eventual  worldwide 
AFIRMS  network.  The  HQ  USAFE  site  receives  planning  data  from  HQ  USAF  and,  if 
necessary,  communicates  it  to  the  wings.  In  USAFE's  North  Atlantic  Treaty 
Organization  (NATO)  role,  USAFE  monitors  the  wing's  resource  status  and 
provides  logistical  support  and/or  resupply  to  the  wings. 


ir 
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HQ  USAFE  tasking  data  consists  of  (but  is  not  limited  to);  WMPs,  OPlans, 
Designed  Operational  Capability  (DOC)  statements,  Concept  Plans  (CONPLANs), 
and  ad  hoc  or  vhat-if  plans.  This  tasking  data  reaches  the  MAJCOM  by  way  of: 

a.  Documents  via  couriers.  Data  in  hardcopy  report  format  is  keyed  into 
the  AFIRMS  site  via  cathode  ray  tube  (CRT).  Hardcopy  interfaces  are 
kept  minimal,  with  interfaces  relying  on  automated  means  as  much  as 
possible. 

b.  Messages  over  AUTODIN  and/or  vocal  orders  over  AUTOVON  and 
AUTOSEVOCOM. 

c.  Computer  tapes  from  the  World  Wide  Military  Command  and  Control 
System  (WWMCCS)  Intercomputer  Network  (WIN). 

d.  System  interface  with  other  MAJCOM  ADP  systems  such  as  MAC'S 
Information  Processing  System  (IPS). 

Resource  data  used  by  HQ  USAFE  consists  of  information  concerning 
munitions,  fuels,  spares,  maintenance  support,  base  status,  aerial  port, 
aircraft,  and  aircrew.  This  information  is  supplied  through  wing  and  MAJCOM 
reports  consisting  of  inputs  from  operations,  personnel,  and  logistics 
resource  managers.  HQ  USAFE  resource  data  includes: 

a.  Detailed  summaries  of  resource  inventory  status  data  maintained  at 
each  wing. 

b.  Aggregated  wing  information  as  reported  by  individual  units. 

c.  Other  in-theatre  resource  information  as  maintained  by  HQ  USAFE. 

d.  Out-of-theatre  resupply  information  as  provided  by  HQ  USAF,  HQ  Air 
Force  Logistics  Command  (AFLC),  HQ  MAC,  etc. 

Assessments  begin  at  the  wing  level  by  collecting  information  on 
unit-possessed  and  MAJCOM-supplied  resources  and  the  status  and  capability  of 
aircrews,  aircraft,  maintenance  support,  and  base  support  facilities.  This 
information  is  compared  against  the  wing's  tasking  to  provide  an  integrated 
look  at  individual  wing  capabilities.  Individual  wing  resource  status 
summaries  are  transmitted  to  HQ  USAFE  where  they  are  aggregated  to  form  a 
theatre-wide  or  MAJCOM-level  force  assessment.  HQ  USAFE  then  transmits  this 
MAJCOM  resource  and  unit  status  data  for  the  Air  Staff  for  use  in  total-force 
assessments . 
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AFIRMS  HQ  USAFE  level  products  provide  capability  assessment  insights  that 
assist  in  objectively: 

a.  Creating  hypothetical  tasking  scenarios. 

b.  Checking  the  validity  of  proposed  tasking. 

c.  Assigning  forces. 


CDRL  0029 


2-2.1/CHG  1 


d.  Distributing/allocating  resources. 

e.  Supporting  Program  Objective  Memoranda  (POM)  deliberations. 

f.  Supporting  crisis  and  wartime  decision  making. 

2.1.1  HQ  USAFE  Subsystem  Architecture.  The  general  subsystem  architecture  for 

A  FIR  MS  sites  is  based  upon  a  centralized  database  and  a  set  of  functional  area  databases 
(see  Figure  2-  1). 

The  centralized  database  is  accessed  via  one  or  more  central  node  modules  (CNMs). 
Each  CNM  services  one  or  more  functional  areas  (FAs)  and  shares  the  centralized 
database  with  any  other  CNMs  comprising  the  central  node. 

2. 1.1.1  Central  Node  Modules.  Each  CNM  possesses  the  following: 


a.  A  full  duplex  high  band  width  communications  path  to  each  on-line  storage 
device  that  has  any  part  of  the  centralized  database  resident  upon  it. 

b.  One  or  more  high  band  width  full  duplex  communications  paths  to  one  or  more 
other  CNMs  comprising  the  central  node.  If  only  two  CNMs  comprise  a  central 
node,  two  communications  paths  between  the  two  are  provided. 

c.  One  private  on-line  storage  device  which  contains  the  system  software  for  that 
CNM  and  which  is  used  for  system  storage  space  only. 

d.  A  copy  of  the  DBMS  being  used  for  the  system.  Control  for  updates  of,  and 
retrievals  from,  the  centralized  database  is  distributed  between  the  CNMs. 
Ideally,  the  physical  updates  and  retrievals  themselves  are  also  distributed 
between  the  CNMs. 


Each  CNM  is  responsible  for  updating  the  FA  databases  attached  to  it  as  required.  It 
is  also  responsible  for  transmitting  the  data  updates  made  by  one  or  more  of  its  attached 
FAs  to  all  other  CNMs  to  allow  them  to  update  their  FA  databases  as  required. 


2. 1.1.2  Functional  Areas.  Each  FA  has  an  intelligent  device  containing  its  own  database 
and  copies  of  required  software. 


The  data  resident  on  the  FA  database  consists  of  update/read  and  read  only  data 
elements.  The  specific  data  resident  is  determined  by  the  data  needed  for  a  functional 
area's  normal  uses.  See  the  HQ  USAFE  Database  Specification  for  details  of  the  data 
requirements  by  functional  user.  Vi  hen  an  update  is  made  at  the  FA,  the  update 
transaction  is  sent  to  the  central  node  to  allow  update  of  the  centralized  database  and  for 
synchronization  of  the  databases  of  other  FAs. 
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2. 1.1.3  Communications.  A  communications  path  is  provided  for  normal  communications 
with  a  higher  level  site,  in  addition  to  this  normal  channel  which  is  shared  between  all 
CN  Ms,  each  CNM  has  an  alternate  temporary  path  to  the  HQ  USAF  site.  Since  this 
alternate  path  is  variable  in  nature,  the  software  is  capable  of  communicating  using  a 
variety  of  protocols  and  speeds. 

A  communications  path  is  provided  for  normal  communications  between  a  FA  device 
and  a  CNM.  In  addition  to  this  normal  channel,  each  FA  has  an  alternate  temporary  path 
of  communications  (i.e.,  a  dial-up  phone  line).  The  HQ  USAF  CNM  has  the  required 
receiving  equipment  to  accept  the  alternate  path  transmission.  (The  HQ  USAFE  CNM 
also  has  the  necessary  receiving  equipment  to  accept  the  alternate  path  communications 
from  the  wing's  FA.)  It  is  possible  for  the  HQ  USAFE  FA  to  use  the  alternate 
transmission  path  to  link  directly  to  a  CNM  at  HQ  USAF.  Interface  specifications  for 
these  alternate  FA  communications  paths,  as  well  as  the  determination  as  to  which  FAs 
require  this  MAJCOM  specific  functionality,  are  defined  during  the  Analysis  Phase  of 
each  functional  block  implementation. 

2.2  HQ  USAFE  Subsystem  Functions.  Three  levels  of  functions  are  of  interest  in  this 
subsystem  specification.  They  are:  Basic  AFIRMS  Functions,  Secondary  AFIRMS 
Functions,  and  System  Functions. 


a.  Basic  AFIRMS  Functions.  The  building  block  functions  which  are  specific  to 

AFIRMS  are  used  (in  different  forms  and  combinations)  to  support  the  user  with 
various  types  of  data/information.  The  Basic  AFIRMS  Functions  at  the  HQ 
USAFE  level  are: 

(1)  Translate  Tasking.  Translates  tasking  so  that  it  can  be  used  in  measuring 
ability  to  perform,  i.e.,  converts  tasking  to  quantities  of  aircraft,  crews, 
munitions,  Petroleum,  Oil  and  Lubricants  (POL),  etc.  required  to 
accomplish  that  tasking.  The  Translate  Tasking  function  assists  in 
evaluation  of  alternative  task  assignments.  HQ  USAFE  products  that  use 
this  function  include: 


(a) 

(b) 

(c) 

(d) 

(e) 

(f) 


Aircraft  Tasking 
Mission  Profile  Definition 
Order  Assignments 
Wing  Flying  Day 
War  Mobilization  Plan 


3  3  3V! 


2-5 


(2)  Define  Resources.  Provides  inventory  status  and  availability  of  resources 
(such  as  fuels,  munitions,  aircraft,  and  crews)  for  use  in  capability 
assessment.  The  Define  Resources  function  assists  in  allocation  of 
physical  resources  and  forecast  results  of  trial  or  final  allocations.  HQ 
USAFE  products  that  use  this  function  include: 


(a)  Munitions  Status 

(b)  Resource  Reallocation 

(c)  Wing  Resource  Summary 

(d)  Wing  Resupply  Schedule 

(з)  Determine  Ability  to  Perform.  Given  current  and  forecast  readiness 
factors,  AFIRMS  transforms  W'MPs,  ATOs,  OPlans,  and  "what-if" 
exercises  into  measurable  tasking;  computes  current  readiness  to  perform 
the  task,  projects  readiness  into  the  future,  calculates  resources 
consumed  by  performing  the  task,  and  prepares  schedules  for  performing 
the  task.  This  function  provides  users  with  the  capability  to  measure  (and 
aggregate)  readiness  and  sustainability  vs.  standard  or  one-time  tasking, 
and  measure  (and  aggregate)  readiness  or  sustainability  vs.  revised 
standards,  and/or  revised  standard  tasking  using  historic  data. 

HQ  USAFE  products  that  use  the  Determine  Ability  to  Perform  function 
include: 

(a)  Base  Fuels  Capability 

(b)  Capability  Perspective 

(c)  Individual  Resource  Capability 

(d)  Integrated  Capability 

(e)  Munitions  Capability 

(g)  Sortie  Generation  Model 

( и )  Aggregate,  Analyze  and  Present  Data.  This  function  deals  with  the  task 
of  properly  grouping  data  from  various  wings  and  MAJCOMs  to  provide 
meaningful  and  useful  data  at  MA3COM  and  HQ  USAF  levels.  It  also 
develops  trend  and  variance  data  to  facilitate  exception  type  reporting  on 
unusual  developments  in  day-to-day  data. 

Aggregation  refers  to  the  creation  of  a  composite  understanding  of  the 
readiness  and  sustainability  of  a  number  of  units.  Thus,  a  MAJCOM  with 
many  reporting  wings,  each  with  its  own  deficiencies  and  strengths,  can 
assess  the  readiness  (and  sustainability)  of  all  units  taken  as  a  whole. 


HQ  USAFE  products  that  use  the  Aggregate,  Analyze,  and  Present  Data 
function  are: 

(a)  Base  Status  Report  Generation 

(b)  Dollars  to  Readiness  Model 

(c)  Resource  Summary  Report  Generation 

(d)  Unit  Status  Report  Generation 


b.  Secondary  AFIR.MS  Functions.  In  order  to  carry  out  the  Basic  AFIRMS 
Functions,  AFIRMS  must  maintain  and  verify  data.  To  help  ensure  the  accuracy 
of  the  data  and  to  take  advantage  of  its  availability,  AFIRMS  provides  a  variety 
of  associated  capabilities  which  are  not  directly  related  to  capability 
assessment.  These  functions  are  secondary  and  some  of  them  may  be 
eliminated  if  the  circumstances  in  which  AFIRMS  operates  were  to  change. 
Examples  of  these  secondary  functions  are:  display  tasking;  perform  ad  hoc 
queries;  and  display  information  on  an  evolving  schedule.  For  a  detailed  listing 
of  these  functions,  refer  to  the  AFIRMS  System  Specification. 

c.  System  Functions.  The  standard  building  block  functions  such  as  graphics  or 
data  mangement  which  might  occur  in  any  system,  and  which,  together  with 
specially  written  subfunctions,  are  used  to  support  the  Basic  and  Secondary 
AFIRMS  Functions.  For  a  detailed  listing  of  these  functions,  refer  to  the 
AFIRMS  System  Specification. 

2.2.1  Accuracy  and  Validity.  The  accuracy  of  the  AFIRMS  database  is  essential  for  the 
generation  of  accurate  measurements.  There  are  two  categories  of  accuracy  and  validity 
that  must  be  addressed.  The  first  is  related  to  electronic  manipulation,  storage,  and 
transmission  of  data  in  the  AFIRMS  system.  The  second  is  related  to  the  interface 
between  the  user  or  other  Air  Force  systems,  and  the  AFIRMS  system. 


a.  Electronic  .Manipulation/Storage/Transmission. 

(1)  The  nature  of  the  models/displays  created  with  AFIRMS  does  not  require 
precision  beyonc  that  achievable  with  off-the-shelf  standard  micro  or 
minicomputers  that  support  hardware  or  software  floating  point 
computations. 

(2)  Errors  in  data  transmissions  will  not  exceed  1  part  in  10^.  Rarity 
checking  and  cyclical  redundancy  checKing  (CRC)  ensure  that  the  data 
actually  used  internal  to  the  AFIRMS  sites  has  an  error  probability  well 
below  this  figure  by  correcting  all  1  -bit  errors.  (Double-bit  errors  are 
detected  but  not  corrected.) 

b.  User  Interfaces  to  AFIRMS.  The  user  interfaces  of  interest  are  those 
interfaces  that  introduce  new  information  into  AFIRMS.  The  concern  is  that 
the  information  destined  to  enter  the  database  be  valid.  Valid  here  means  that: 


(1)  The  individual  entering  the  information  is  authorized  to  do  so  (i.e.,  only- 
logistics  personnel  may  be  authorized  to  update  logistics  information, 
using  logistics  data  forms). 
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(2)  The  information  is  as  "error  free  as  possible."  This  suggests  that  input 
data  must,  in  general,  be  entered  through  well-engineered  interfaces  that 
prompt  the  user  and  check  field  contents. 

(3)  Certain  information  passed  into  the  database  has  sufficient  criticality  to 
require  verification  beyond  that  identified  in  (2)  above,  prior  to  database 
updates.  This  verification  occurs  via  supervisory  review.  Under  this 
method,  the  data  is  entered  by  an  authorized  individual.  However,  the 
information  cannot  update  the  database  or  be  transmitted  to  higher 
headquarters  by  the  individual  who  entered  it  until  a  supervisor  authorizes 
the  AFIRM5  system  to  accept  the  data.  The  method  of  authorization 
might  require  that  the  supervisor  log  on  to  the  AF1RMS  system  and  enter 
an  "unlocking"  command  that  allows  the  data  to  be  entered  and  the 
database  updated.  Information  requiring  supervisory  review  is  kept 
minimal.  Specific  data  requiring  this  quality  assurance  technique  are 
identified  during  the  Analysis  Phase  of  each  functional  block 
implementation. 

c.  System  Interfaces  to  AFIRMS.  Data  obtained  by  interface  with  other  data 
systems  is  subject  to  the  same  data  accuracy  and  validity  criteria  as  for  user 
input  data. 


2.2. 1.1  Data  Accuracy.  AFIRMS  uses  five  main  approaches  to  ensure  the  accuracy  and 
currency  of  data. 

a.  Provide  benefits  to  the  organizations  which  input  readiness  data.  If  the 
organization  which  inputs  data  receives  benefits  from  the  system,  then  it  is 
motivated  to  ensure  that  data  entered  is  current  and  accurate. 

b.  Simplify  data  input  by  using  simple  devices  and  by  grouping  inputs.  For 
example,  a  bar  code  reader  is  a  candidate  device  for  entering  a  complex 
identification  number  that  might  be  subject  to  error  if  entered  via  keyboard. 

c.  Use  automated  edit  check  as  well  as  checks  for  the  reasonableness  of  input  data 
against  stored  parametric  values.  That  is,  all  inputs  are  programmatically 
edited  to  further  ensure  the  accuracy  and  integrity  of  the  database.  The 
system  validates  length,  format,  and  legal  values  of  all  formatted  alphanumeric 
input  data. 

d.  Automatically  review/check  all  data  entry  information  for  consistency  against 
other  related  information. 

e.  Obtain,  edit,  and  incorporate  data  and/or  assessments  from  other  automated 
systems. 


2.2.2  Timing. 

User  Response  Time.  AFIRMS  is  an  information  processing  system  which  is 
user  intensive;  that  is,  in  general,  users  enter  data  through  a  data  capture 
device  and  request  readiness  status  onto  an  output  display.  Thus,  it  is 
imperative  that  AFIRMS  response  time  to  user  requests  be  kept  minimal. 


a. 


Response  time  as  it  applies  to  user  terminals,  consists  of  two  parts;  command 
acceptance  and  command  execution. 

(1)  Command  Acceptance.  Command  acceptance  is  the  time  between  the 
user's  initiating  transmission  of  a  command  or  transaction  to  the  system 
(such  as  by  depression  of  the  ENTER  key  or  entry  of  the  last  character  of 
a  menu  response)  and  the  appearance  of  the  first  line  of  the 
acknowledgment  from  the  system  on  the  user's  terminal  that  the  message 
has  been  received  or  an  error  condition  exists.  AFIRMS,  under  loaded 
conditions  (more  than  85%  of  terminals  in  use)  supports  a  command 
acceptance  time  of  less  than  2.5  seconds  90%  of  the  time.  At  no  time 
does  command  acceptance  time  exceed  six  seconds. 

(2)  Command  Execution.  Command  execution  is  the  elapsed  time  between 
the  command  or  transaction  entry,  and  the  appearance  of  the  first  line  on 
the  user's  display  terminal  (excluding  graphics). 

(a)  For  functions  such  as  command  entry,  text  editing  or  message 
writing  applications,  the  appearance  of  a  keyed  character  on  the 
screen  is  immediate  in  the  perception  of  the  user. 

(b)  Queries.  AFIRMS  allows  for  local  (intrasite)  queries  only,  with 
response  times  as  follows: 

J.  Simple.  Response  time  of  1  to  3  seconds. 

2  Medium.  Response  time  of  4  to  10  seconds. 

3  Complex.  Response  time  of  1 1  to  30  seconds. 

Categorization  of  specific  queries  within  these  definitions  is 
accomplished  during  the  Analysis  Phase  of  the  functional  block 
developments.  These  times  do  not  include  sortie  generation  model, 
dollars  to  readiness  model,  or  similar  model  execution  times. 


b.  Data  Currency.  When  changes  are  made  to  data  at  the  functional  area  level, 
those  changes  are  transmitted  to  the  central  site  database.  After  the  central 
database  is  updated,  the  changes  are  subsequently  transmitted  to  other  functional 
areas  having  the  data  in  question  resident  on  their  local  database.  The  time  that 
it  takes  to  complete  the  transactions  on  the  central  database  and  all  affected 
functional  areas  designates  the  currency  of  data  at  the  site. 


(1)  Mission-Related  Data  - 


Within  a  site  this  time  period  must  be  less  than  three 
minutes  for  mission-related  data  90%  of  the  time 
with  the  system  operating  in  a  normal  mode. 

AFIRMS  mission-related  data  consists  of  current 
tasking  and  current  primary  resource  status 
information  or  that  data  associated  with  a  crisis 
mode.  Primary  resources  are  those  resources 
directly  utilized  by  the  capability  assessment  model. 
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(2)  Non-Mission-Related  Data  -  Data  currency  within  a  site  must  be 

achieved  within  one  hour  for 
non-mission-related  data  90%  of  the 
time  with  the  system  operating  in  a 
normal  mode.  AFIRMS  non-mission- 
related  data  consists  of  that 
information  relating  to  ad  hoc, 
historic,  exercise,  or  contingency 
simulations  which  neither  relate  to  the 
current  situation  nor  are  designated  as 
crisis  mode  items. 

c.  Data  Age.  The  maximum  time  span  allowed  for  known  data  updates 

between  MAJCOM  and  HQ  USAF  sites  is  six  hours,  regardless  of  state  of 
change  for  the  data. 


2.3  Flexibility.  AFIRMS  provides  an  architecture  that  matches  the  specific 
requirements  of  each  MAJCOM  to  an  AFIRMS  site  with  compatible 
hardware/software  capability.  Additionally,  it  has  the  capability  to  grow, 
i.e.,  add/change  system  focus  as  time  passes.  Capabilities  incorporated  for  i 
adapting  the  HQ  USAFE  subsystem  to  changing  requirements  include  the  following: 


a.  Configuration  of  AFIRMS  sites  from  modular  hardware  and  software 
components.  The  modular  applications  software  is  written  in  DoD 
standard  host  independent  high  order  languages  (HOL)  for  ease  of 
transportability  among  different  hardware  configurations.  Acceptable 
HOLs  are  ADA,  C,  or  other  strongly  typed  languages  which  support 
modular  software  design,  readability  and  increased  maintainability. 

b.  A  hardware/software  building  block  approach,  coupled  with 
transportable  software,  to  facilitate  expansion  of  operational  AFIRMS 
in  the  future. 

c.  Utilization  of  DoD  standardized  data  communications  protocols  and 
external  user  interfaces.  AFIRMS  implements  DoD  standard  protocols 
for  network  and  distributed  system  data  communications  and  terminal 
interfaces.  Utilization  of  the  DoD  standard  protocols  provides  for 
interoperability  among  different  vendor  equipments,  existing  and 
developmental  Air  Force  Automated  Data  Processing  (ADP)  systems,  and 
is  in  accordance  with  Air  Force  policy  and  guidance. 

d.  Ability  to  interface  an  AFIRMS  site  to  other  Air  Force  or 
MAJCOM-unique  ADP  systems  after  the  AFIRMS  site  has  been  designed  and 
installed.  AFIRMS  software  is  structured  so  as  to  provide  for  new 
system  integration  to  the  greatest  extent  possible.  This  is 

facilitated  by  maintaining  distinct  layers  of  software,  as  in  the 
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International  Standards  Organization  (ISO)  7-layer  Reference  Model, 
and  by  the  use  of  controlled  standardized  data  gateways  (intersite  or 
intrasite  standard  data  communications  formats). 


Ability  to  support  secondary  (or  backup)  interfaces,  by  which  an 
intermediate  AFIRMS  site  may  be  bypassed.  For  example,  the  ability 
of  a  functioned  area,  in  place  or  deployed,  to  communicate  directly 
with  a  MAJCOM. 


SECTION  3.  ENVIRONMENT 


3.1  Equipment  Environment,  Equipment  is  provided  to  HQ  USAFE  (and  all  other  AFIRMS 
sites)  on  an  "as  needed"  basis.  AFIRMS  uses  existing  facilities  and  equipments  wherever 
possible.  However,  at  a  minimum,  each  AFIRMS  site  contains  the  equipment  required  for 
the  Central  Node  and  one  Functional  Area  workstation.  The  Central  Node  contains  the 
AFIRMS  database  for  that  site  as  well  as  the  communications  support  for  site  to  site 
communications. 

AFIRMS  utilizes  standard  Air  Force  equipment  sources  such  as  the  Air  Force 
Standard  Multiuser  Small  Computer  initiative  by  the  Air  Force  Computer  Acquisition 
Center,  TEMPEST  and  Phase  IV  Program  equipment  sources.  AFIRMS  is  designed  to  allow 
for  the  integration  of  different  computers,  peripherals,  and  communications  standards 
throughout  the  system.  This  provides  for  a  faster  and  more  cost  effective  AFIRMS 
development,  and  a  higher  degree  of  operational  flexibility. 


3.1.1  Central  Node  Equipment.  Each  AFIRMS  site  contains  a  Central  Node  consisting  of 
the  following  equipment; 


a.  One  or  more  processors,  each  capable  of  handling  four  or  more  functional 
areas.  Each  processor  is  a  32-bit  machine  with  at  least  a  24-bit  address 
structure.  Each  processor  has  several  high  bandwidth  full  duplex 
communications  paths  to  the  other  processors,  if  any,  in  the  central  node.  Each 
processor  has  the  ability  to  connect  three  or  more  terminals. 

b.  One  or  more  direct  access,  high  speed  storage  devices  capable  of  containing  the 
centralized  data  base  and  capable  of  being  logically  accessed  by  multiple 
processors.  Each  high  speed  storage  device  has  at  least  one  high  bandwidth  full 
duplex  communications  path  to  each  of  the  processors  in  the  central  node. 

c.  One  direct  access,  high  speed  storage  device  capable  of  containing  all  software 
and  system  files  for  each  processor  in  the  Central  Node. 

d.  A  mass  storage  device,  i.e.  9-track  tape  or  optical  storage  device,  capable  of 
being  accessed  by  multiple  processors. 

e.  A  communications  controller  capable  of  handling  all  external  communications 
lines  and  capable  of  being  accessed  by  multiple  local  processors. 

f.  Encryption  devices  for  each  physical  line  that  may  pass  classified  data.  The 
encryption  device  is  able  to  operate  in  a  synchronous  or  asynchronous  mode  and 
to  operate  at  the  speeds  identified  in  Section  3.1.4  of  this  subsystem 
specification,  "Communications  Equipment." 

SOFTbi 


33401 


3-1 


g.  Power  conditioning  and  failure  protection  mechanisms  are  required  as  stated  in 
Section  3. 1.5. 2  of  this  subsystem  specification,  "Electrical  Power."  All  "wall 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Filtered 

power  is  also  required  for  systems  that  process  classified  data  to  prevent  data 
emanations.  Power  failsafe  backup  provisions  are  provided  to  preserve  memory 
in  the  event  of  power  failure.  Backup  power  terminates  during  normal 
shutdown. 

h.  A  CRT  terminal  and  line  printer  for  system  maintenance  and  operator  use. 

i.  Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  four 
megabytes  of  user  memory  is  required.  This  user  memory  is  expandable  (in 
minimum  512K  byte  increments)  up  to  at  least  10  megabytes.  All  memory 
specifications  are  made  in  8-bit  bytes.  The  physical  organization  of  the  main 
memory  is  modular  so  that  a  failure  in  one  module  (except  the  module 
containing  the  operating  system  or  similar  support  software)  does  not  deprive 
the  system  of  the  remaining  memory.  Memory  must  be  byte  addressable  and 
volatile. 

(1)  Error  Detection.  As  a  minimum,  a  memory  error  detection  and  correction 
feature  are  provided  that  detect  double  bit  errors  and  correct  all  single 
bit  errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  memory  areas  not 
allocated  to  that  program  is  required. 


3.1.2  Functional  Area  Equipment.  Each  functional  area  which  needs  to  access,  enter,  or 
modify  AF1RMS  data  is  provided  with  a  functional  area  workstation  to  communicate  with 
the  Central  Node.  Each  functional  area  workstation  contains  the  following  equipment: 


a.  One  processor  capable  of  handling  one  or  more  users  depending  on  the  needs  of 
the  functional  area.  The  processor  is,  at  a  minimum,  a  16-bit  machine. 

b.  One  direct  access,  high  speed  storage  device  capable  of  containing  the  local 
database  and  the  software/system  files. 

c.  A  mass  storage  device,  e.g.,  floppy  disk  drive. 

d.  A  communications  controller  capable  of  handling  all  external 
asynchronous/synchronous  communications  between  the  functional  area 
workstation  and  the  central  node. 

e.  Several  miscellaneous  input/output  devices.  The  number  of  each  type  of  device 
depends  on  the  requirements  of  the  functional  area,  and  is  be  determined  during 
the  Analysis  Phase  that  precedes  implementation  at  each  site. 


f. 


An  encryption  device  for  communicating  with  the  Central  Node  if  the 
workstation  is  to  handle  classified  data.  The  encryption  device  is  able  to 


operate  either  in  a  synchronous  or  asynchronous  mode  and  to  operate  at  the 
speeds  required  by  the  communications  lines. 
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g.  Power  conditioning  and  failure  protection  mechanisms  are  required.  All  "wall 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Filtered 
power  is  also  required  for  systems  that  process  classified  data  to  prevent  data 
emanations.  Power  failsafe  backup  provisions  are  provided  to  preserve  memory  in 
the  event  of  power  failure.  Backup  power  must  terminate  during  normal  shutdown. 

h.  Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  two  megabytes 
of  user  memory  is  required.  This  user  memory  is  expandable  (in  minimum  512 K 
byte  increments)  up  to  at  least  S  megabytes.  All  memory  specifications  are  made 
in  S-bit  bytes.  The  physical  organization  of  the  main  memory  is  modular  so  that  a 
failure  in  one  module  (except  the  module  containing  the  operating  system)  shall 
not  deprive  the  system  of  the  remaining  memory. 

(1)  Error  Detection.  As  a  minimum,  a  memory  error  detection  and  correction 
feature  is  provided  that  detects  double  bit  errors  and  corrects  all  single  bit 
errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  memory  areas  not  allocated 
to  that  program  is  required. 

3.1.3  Input/Output  Devices.  HQ  USAFE  device  requirements  for  CRT  terminals,  printers, 
disk  drives  and  magnetic  tape  drives  are  determined  during  the  Analysis  Phase  of  each 
block  implementation. 

a.  CRTs  must  possess  the  following  characteristics; 

(1)  Monochrome  Terminals:  Alphanumeric  keyboard  and  video  display; 
interface  via  standard  RS-232-C  port;  ability  to  function  as  a  system 
console;  and  sound  an  audible  tone  or  "BEEP"  when  the  ASCII  "BEL" 
character  or  its  equivalent  is  received. 

(a)  Keyboards  must  possess  the  following  characteristics: 

J_  Be  capable  of  generating  the  ASCII  128-character  subset  in 
accordance  with  (IAW)  FIPS  PUB  1. 

2  At  a  minimum,  conform  to  the  ANSI  Standard  X4. 14-1971. 

3  Have  a  repeat  function  for  all  printable  ASCII  characters, 
cursor  controls,  and  spacing  functions. 

U  Have  separate  keys  for  carriage  return,  control,  escape,  and 
spacing  functions. 

2  Have  a  minimum  of  16  programmable  function  keys. 

Have  a  numeric  keypad  to  the  right  of  the  character  keys  and 
allow  numeric  entries  from  either  the  regular  character  key  or 
the  numeric  keypad. 
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Have  at  least  four  cursor  movement  keys  separate  from 
function  keys. 


8  Have  a  detachable  keyboard. 

9  Have  a  (screen)  hardcopy  function. 

(b)  Video  Displays  must  possess  the  following  characteristics: 

_1_  Display  a  minimum  of  24  lines  of  132  characters  each. 

2  Characters  displayed  consist  of  the  ASCII  95-character  subset 
IAW  FIPS  PUB  15,  Section  1. 

3  If  the  dot  matrix  character  generation  technique  is  used,  the 
matrix  must  be  at  least  7x9. 

4  Full  descenders  will  be  used  on  the  lower  case  such  as  "g,  j,  p, 
q,  y"  and  appropriate  special  characters. 

_5  Implement  a  visible  cursor  denoting  the  next  character 

position  in  such  a  manner  that  its  location  is  obvious  to  the 
operator  and  does  not  obscure  any  information  (excluding 
underline)  which  may  be  displayed  at  that  position. 

6  The  cursor  must  be  addressable  and  the  capability  must  be 
provided  for  the  applications  program  to  clear  the  display  and 
to  position  the  cursor  at  any  location  on  the  screen. 

7  Have  a  non-glare  viewing  surface. 

8  Provide  reverse  video,  bold,  blink,  and  underscore  capabilities 
under  application  program  control. 

9  Brightness  must  be  externally  adjustable  by  the  terminal 
operator. 

10  The  display  must  be  green  or  amber. 

1  1  Have  selectable  terminal  transmission  rates  of  300,  1200, 
2400,  4800,  and  9600  bits  per  second  (bps). 

I  2  Have  a  minimum  1  1-inch  screen  measured  diagonally. 

1  3  Have  smooth  scrolling  capability. 

1 4  Support  shading  and  marking  patterns  (preprogrammed  and 
programmable). 

(c)  Other  Required  CRT  Terminal  Characteristics: 

_1_  Local  memory 

2  Built-in  diagnostics  and  testing 
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_3  TEMPEST  certified  -  for  terminals  which  display  classified 
information 

4  Screen  print  function 

(2)  Color  Graphics  Terminals  must  possess  the  following  characteristics: 

(a)  Minimum  of  16  special  function  (programmable)  keys.  Refer  to 
Table  3-1  for  some  of  the  required  function  key  features. 

(b)  10T,  of  the  terminals  require  a  video  interface  board  for  use  with 
video  projectors 

(c)  Screen  definition  of  not  less  than  720x484  individually  addressable 
and  color  definable  pixels  (i.e.,  medium  resolution) 

(d)  Minimum  1  1"  CRT  screen 

(e)  TEMPEST  certified  -  for  terminals  which  display  classified 
information 

(f)  Support  9600  baud  rate 

(g)  Display  a  minimum  of  16  colors 

(h)  Screen  print  function 

b.  Printers  must  possess  the  following  characteristics; 

(1)  Letter  Quality  Printers  must: 

(a)  Print  at  least  55  characters  per  second  (CPS). 

(b)  Print  at  least  132  characters  per  line  (CPL). 

(c)  Have  a  pressure-feed  mechanism,  interchangeable  tractor  feeq  and 
an  automatic  single  sheet  feeder. 

(d)  Print  the  complete  95  character  ASCII  subset  LAW  FIPS  PUR  1  5, 
Section  1. 

(e)  Have  operator  selectable  print  spacing  of  10  pitch,  12  pitch,  and 
proportional  spacing. 

(f)  Accept  forms  from  u  1/2  to  at  least  14  7/8  inches  in  width. 

(g)  Print  clearly  up  to  3  part  paper. 

(h)  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(i)  Provide  at  least  one  font  which  is  readable  by  an  optical  character 
reader  (OCR). 

(|)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  tha 
indicate  the  standard  first  print  position. 


(k)  Have  operator  controls  for  power  online/of fline,  advance  to  top  of 
form  and  manual  adjustment  of  vertical  and  horizontal  paper 
alignment. 

(l)  Be  TEMPEST  certified,  when  used  for  classified  information 
printout. 

(2)  Dot  Matrix  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  200  CPS  at  132  characters  per  line  at  10  characters 
per  inch  (CPI). 

(b)  Have  dot  addressable  graphics  with  a  minimum  resolution  of  70  dots 
per  inch,  vertical  and  horizontal. 

(c)  Provide  correspondence  duality  print  capability  of  at  least  40  CPS 
at  10  CPI. 

(d)  Use  an  operator  adjustable  pin  feed  tractor  for  positive  form 
registration  movement. 

(e)  Print  the  complete  95  character  ASCII  subset  I  AW  FIPS  PUB  15, 
Section  1. 


(f)  Accept  forms  ranging  from  4  1/2  to  14  7/8  inches  in  width. 

(g)  Print  full  descenders  used  on  the  lower  case  characters  "g,  j,  p,  q,  y" 
and  appropriate  special  characters. 

(h)  Print  6  and  8  lines  per  inch  (LP1),  operator  selectable. 

(i)  Print  clearly  using  up  to  3  part  paper. 

(j)  Have  controls  for  power,  online/offline,  advance  to  top  of  form  and 
manual  adjustment  of  vertical  and  horizontal  paper  alignment. 

(k)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  that 
indicate  the  standard  first  print  position. 

(l)  Provide  program  control  of  line  feed  and  form  feed. 

(m)  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(n)  Be  TEMPEST  certified. 

(3)  High  Speed  (Line)  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  500  lines  per  minute  (LPM)  (at  132  CPL)  using  the 
character  set  specified  in  (b)  below. 

(b)  Print  the  complete  95  character  ASCII  subset  I  AW  FIPS  PUB  1  5, 
Section  1. 


(c)  Support  horizontal  spacing  of  10  or  12  CPI. 
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(d)  Have  vertical  spacing  of  6  or  S  L  PI  switch  or  oroprau.mer  selectable. 

(e)  Print  at  least  132  characters  per  line. 

(f)  Print  clearly  using  up  to  3  part  paper. 

(g)  Have  vertical  format  control  via  programmer  or  printer. 

(h)  Be  TEMPEST  certified. 

(i)  Have  a  diagnostic  light-emitting  diode  (LED)  indicator  for  status. 

(j)  Interface  via  RS-232-C  sec  A  port  and  parallel  port. 

(4)  Color  Graphics  Printers  must  possess  the  following  characteristics: 

(a)  Plot  the  displayed  graph  in  the  same  ratio  (horizontal  to  vertical)  as 
the  screen  display,  in  no  more  than  90  seconds. 

(b)  Provide  minimum  resolution  of  IOOxS5  horizontal  to  vertical  dots  per 
inch. 

(c)  Print  at  least  eight  colors. 

(d)  Print  on  bond  paper  and  transparency  (developing  of  transparency  not 
acceptable). 

(e)  Interface  via  RS-232-C  serial  port  or  parallel  port. 

(f)  Accept  a  minimum  paper  size  of  $.5x1  1  inches. 

Floppy/Microfloppy  Disk  Drives  must  possess  the  following  characteristics: 

(1)  Minimum  of  two  read/write  heads  to  provide  access  to  double-sided  disks. 

(2)  Provide  a  formatted  storage  capacity  for  one  diskette  of  at  least  1.5 
megabytes. 

(3)  Use,  at  a  minimum,  a  5.25  inch  double  sided/double  densitv  diskette  for 
floppy  disk  drives  and  3.5  inch  diskette  for  microfloppy  disk  dnves. 

(4)  Be  compatible  with  FA  workstation  hardware  selection. 

Magnetic  Tape  Drives  must  possess  the  following  characteristics: 

( 1)  Be  nine  (9)  track. 

(2)  Support  a  10.5  inch  reel  of  .5  inch  by  2400  foot  standard  reel  tape. 

(3)  Support  speed  read/write  operations  at  a  minimum  of  7  5  inches  per  second 
(IPS),  streaming  at  a  minimum  of  200  IPS. 

(4)  Perform  error  checking  on  all  read  operations. 


(5)  Perform  a  read  after  write  with  error  checking  on  all  write  operations. 

(6)  Have  write  protection  and  beginning  and  end  of  tape  sensor. 

(7)  Support  a  minimum  of  dual-density  (1600/6250  bits  per  inch  (BPI))  tape 
read  and  write  capability. 


3.1.4  Communications  Equipment.  Communications  equipment  is  provided  to  supply  both 
a  primary  and  a  secondary  secure  communications  path  to  all  higher  and  lower  level  sites. 
Requirements  for  specific  types  and  quantities  of  communications  hardware  are 
determined  during  the  Analysis  Phase  that  precedes  implementation  of  each  functional 
block  at  each  site. 


3. 1.4.1  Primary  Intrasite  Communications.  Primary  communications  equipment  between 
central  nodes  and  functional  area  workstations  provides  the  following  capabilities; 


a.  Encryption  of  both  classified  and  unclassified  data  transmitted  to  and  from  a 
functional  area. 

b.  A  transmission  rate  of  9600  baud  and  greater,  using  either  asynchronous  or 
synchronous  equipments. 

c.  A  24  hour  a  day  dedicated  line  from  the  central  node  to  each  functional  area 
workstation. 

O 

d.  Conditioning  to  a  bit  error  rate  of  1  in  10  . 


3. 1.4.2  Secondary  Intrasite  Communications.  Secondary  (backup)  communications 
equipment  provides  the  following  capabilities; 


a.  Encryption  of  data  transmitted  between  sites  and  classified  data  transmitted 
between  a  functional  area  and  its  central  node. 

b.  A  transmission  rate  of  300  baud  and  greater,  using  either  asynchronous  or 
synchronous  equipments. 

c.  Multiple  physical  paths  for  a  single  logical  path  (i.e.,  rerouting). 

d.  Availability,  as  required,  in  the  event  primary  communications  fail.  Over  a  given 
24-hour  period,  secondary  media  are  accessible  at  least  S0O  of  the  time. 


3. 1.4.3  Communications  Hardware. 


a.  Modems: 

(1)  Limited  Distance  Modems.  Limited  distance  modems  are  required  for 
on-base  use.  The  modems  must  be  capable  of  operating  over  available 
non-conditioned  voice  grade  telephone  lines  at  distances  of  at  least  6  miles. 
The  following  characteristics  are  required: 

(a)  Switchable  and  capable  of  transmitting  and  receiving  data  at  rates  of 
300,  600,  1200,  2400,  4800,  and  9600  bits  per  second  (BPS)  up  to  6  miles. 

(b)  The  limited  distance  modem  shall  meet  EIA  Standard 
EIA-RS-232-C/CC1TT  Recommendation  V.24  for  interfacing  with 
external  equipment. 

(2)  Long  Distance  Modems.  Modems  used  outside  the  United  States  (Europe, 

Asia)  on  non-conditioned  commercial  telephone  lines.  The  modem  is  a 
CODEX/V.29  data  modem  model  21962  ar.u  must  be  homologated  (PTT 
option)  to  the  country  where  the  system  is  installed.  The  CODEX  Universal 
PTT  option,  Product  code  22120,  is  provided  when  required. 

b.  Line  Drivers.  Line  drivers  are  required  to  boost  the  electronic  signal  for 
communications  between  modems  and  CRTs  over  long  distances  (i.e.,  75  feet  or 
more). 

c.  Encryption  Devices.  NSA-endorsed  Data  Encryption  Standard  (DES)  devices  are 
required.  Functionality  may  be  combined  for  encryption  devices  and  long/limitea 
distance  modems. 

3.1.5  Environmental  and  Physical  Facilities.  A  FIR  MS  equipment  must  operate  throughout 
the  ranges  of  electrical  power  and  environmental  tolerances  stated  below. 

3. 1.5.1  Space. 


Site  Locations.  Systems  are  installed  at  various  Air  Force  installations  in 
Europe.  The  central  node  location  space  ranges  from  a  minimum  of  20  square 
feet  for  the  smallest  configuration,  to  a  maximum  of  200  square  feet  for  trie 
largest  configuration. 


Flooring.  Equipment  shall  not  require  raised  flooring.  T'  .e  flooring  -ica  be 
carpeted.  There  will  he  no  special  static  control  facilities. 

‘.'oiling  Height.  Tr.i-  distance  from  the  floor  surface  to  the  unobstructed  ceil 
is  at  least  8  feet. 

Access  Route.  Utuc'c  m  t  is  installed  in  ouilclings  with  access  being  the  u/e 
a  normal  office  door  wars .  Additionally,  some  equipment  is  installed  ,n 
facilities  with  vault  doors,  raised  thresholds,  and  access  by  stairwass.  so"-o 
facilities  are  •■■staOl.sr  ed  ■  ou. outer  facilities  with  a  double  door  access  route. 


3. 1.5.2  Electrical  Power.  All  equipments  must  be  capable  of  operating  within  the 
requirements  of  MIL-E-4158  and  are  further  defined  by  the  following: 


a.  Voltage  regulation  steady  state  +  10%  to  -15% 

b.  Voltage  disturbances  30  3£>  for  less  than  0.5  seconds 

Momentary  undervoltage  -100%  acceptable  to  20  millisei 

Transient  overvoltage  200%  for  less  than  20  milliseco 

Surges  I  AW  IEEE  587-1980 

c.  Voltage  harmonic  distortion  +3%  -5%  (with  linear  load) 

d.  Frequency  variation  50/60Hz  plus  or  minus  1Hz 

e.  Frequency  variation  rate  of  change  1  Hz/second 

f.  Power  factor  0.8 

g.  220/240  Volts  +or-10%, 
single  phase,  2  wire. 

h.  105/1  10  Volts  +or-10%, 
single  phase,  2  wire. 

In  addition,  an  electrical  power  fault  detection  device  is  provided  to  prevent 
equipment  failure  (e.g.,  disk  head  crash). 


-100%  acceptable  to  20  milliseconds 
200%  for  less  than  20  milliseconds 


I  AW  IEEE  587-1980 


+  3%  -5%  (with  linear  load) 
50/60Flz  plus  or  minus  1Hz 
1  Hz/second 


3. 1.5.3  Air  Conditioning.  The  ambient  temperature  will  be  maintained  by  the  U.5. 
Government  between  60  and  90  degrees  Fahrenheit  with  a  relative  humidity  of  between  20 
and  90  percent,  non-condensing.  No  special  dust,  static  electricity  control,  or  chilled 
water  facilities  are  available.  The  computer  is  integrated  with  the  air  conditioning 
system  to  provide  automatic  thermal  shutdown  to  prevent  equipment  failure  during 
extreme  high  or  low  temperature  conditions. 

3. 1.5.4  Remote  Locations.  Remote  equipment  is  installed  in  various  office  environments 
within  L.S.  Air  Force  organizations.  Terminals,  office  printers,  and  modems  shall  fit  on 
normal  table  tops  or  desk  surfaces. 


3. 1.5.5  TEMPEST  Requirement.  All  equipments,  connectors,  and  cabling  that  convey 
classified  information  must  meet  the  limits  specified  in  NACSIM  5  1 00 A.  All  equipment 
must  oe  on  the  Preferred  Products  List  (PPL)  or  approved  by  AFC5C/EPV  San  Antonio, 
TX  7824  3. 


VI  '.LI 
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3.2  Support  Software  Environment.  AFIRMS  software  is  broken  up  into  two  general 
categories:  Applications  Software  and  Support  Software.  Applications  Software  is  that 
software  which  applies  specified  algorithms  to  a  given  data  set,  and/or 
stores/retrieves/ formats/analyzes/displays  a  given  set  of  data.  Applications  software 
programs/algorithms  are  enumerated  and  defined  in  the  AFIRMS  Transforms  and  Models 
Document.  This  paragraph  describes  the  support  software  which  interfaces  with  the  HQ 
ESAFE  subsystem  applications  software  to  create  the  environment  necessary  to  support 
AFIRMS'  general  functionality  and  the  AFIRMS  Applications  Software. 


3.2.1  Central  Node  Support  Software.  Each  AFIRMS  Central  Cede  requires  the  support 
software  identified  in  this  section. 


3.2. 1.1  Operating  System.  A  general  purpose  operating  system  provides  file  access, 
program  control,  and  data  communications  interfaces.  Operating  system  operation  (e.g., 
device  I/O)  must  not  significantly  impact  the  timing  and  flexibility  of  AFIRMS  operational 
software.  The  operating  system  must  be  able  to: 

a.  Concurrently  process  a  combination  of  interactive  and  local  batch  processing. 

b.  Support  a  multi-programming  environment. 

c.  Support  both  file  and  record  level  locking  protection  capabilities. 

d.  Provide  control  over  all  hardware  and  software. 

e.  Support  logical  as  well  as  physical  mode  access  to  all  system  peripheral  devices 
including  terminals. 

f.  Pe  capable  of  detecting  and  marking  bad  blocks  while  formatting  system  and 
data  diSKS  as  el  1  as  during  normal  operation. 

g.  s  jpport  up  to  8  concurrent  interactive  users  in  a  minimum  configuration  and  up 
to  20  concurrent  interactive  users  in  a  maximum  configuration. 

h.  Provide  access  to  a  calendar  clock  which  provides  the  calendar  date  and  time 
with  a  resolution  of  one  microsecond  (for  purposes  of  statistical  performance 
analysis  data  collection)  showing  hours,  minutes,  and  seconds  for  time;  and  day, 
month,  and  year  for  date.  This  calendar  clock  is  accessible  to  all  programming 
languages. 


Detect  and  terminate  attempts  to  read  or  write  outside  of  any  programs 
allocated  memory  and  detect  and  terminate  attempts  by  any  applications 
program  to  execute  privileged  and  undefined  instructions. 


j.  Provide  high  order  language  (HOL)  runtime  support  for  input/output  (I/O), 
scheduling,  and  interprocess  communication  and  coordination. 

k.  Provide  memory  fault  detection  and  recovery  capabilities. 

l.  Support  high  level  control  of  interrupt  detection,  definition,  and  processing 
activities. 

m.  Provide  the  capability  to  perform  dynamic  load  analysis  and  reporting. 

n.  Provide  host  language  interfaces  (system  directives)  to  system  functions. 


3.2. 1.2  Utility  Routines.  The  following  utility  routines  are  required: 

a.  File  Management  System 

b.  Sort  and  Merge  Utility 

c.  Translation  Utility  (character  code  conversion,  e.g.  ASCII  to  EBCDIC  and 
vice-versa) 

d.  Save  and  Restore  Utility  (to  and  from  tape) 

e.  Security  Utility  (Error  surveillance  and  alerts;  to  recognize,  record  and  indicate 
misuse,  and  attempted  misuse,  of  the  system.) 

f.  Logging/,- Accounting  Utility  (An  automated  audit  trail  will  show:  access  made 
to  files;  how,  and  from  where  the  access  was  initiated;  the  identity  of  the 
person  or  process  that  initiated  the  access;  and  all  unauthorized  attempts.) 

g.  Diagnostic  Software 

h.  Mail  U tilitv 


3.2. 1.3  Communications  Software.  The  specific  requirements  for  communications 
software  are  determined  during  the  Analysis  Phase  that  precedes  implementation  at  each 
site.  However,  at  a  minimum,  a  host  interface  to  the  Defense  Data  Network  (DDN)  is 
required  for  each  AF1RMS  site.  This  interface  implements  the  full  DDN  protocol  suite, 
and  supports  site-to-site  communications  over  the  DDN.  It  also  provides  the  standard 
DDN  services  of  terminal-to-host  communications,  file  transfer,  and  electronic  mail  to 
isers  of  tne  \FIRMS  svstem.  Connection  to  the  DDN  is  via  the  ARPANET  network 
access  protocols  or  X.2N  Host-to-host  communication  snail  be  via  the  Transmission 
Control  Protocol  (TCP),  MIL-bTD  1778,  and  Internet  Protocol  (IP),  MIL-STD  1777.  The 
services  which  are  supported  are  TELNET,  File  Transfer  Protocol  (FTP\  and  the  s:mple 
Mail  Transfer  Protocol  (SMTP). 


Encryption  services  provided  by  the  DDN  are  limited  to  SECRET  security 
classifications.  However,  with  user  acquisition  of  TOP  SECRET  security  classification 
encryption  devices,  the  DDN  can  be  accessed  for  transmission  of  TOP  SECRET 
information. 

3.2. 1.4  Database  Management  System  (DBMS).  The  AFIRMS  DBMS  performs  the  action 
of  retrieving  a  record  from  a  file,  writing  a  record  to  a  file,  and  deleting  and  creating 
records  in  a  file.  The  DBMS  also  performs  functions  such  as  opening  and  closing  the 
database,  transaction  flow,  handling  of  the  DBMS  command  language  requests,  transaction 
parsing,  and  automatic  editing  on  input.  In  addition,  the  DBMS  allows  for  host  language 
interfaces;  save  and  restoration  of  full  or  partial  database  images;  restart  and  recovery 
capability  with  multi-user  and  multi-thread  concurrency  controls;  and  some  level  of 
distributed  or  decentralized  data  management  with  the  appropriate  synchronization  and 
concurrency  controls.  The  specific  level  of  data  synchronization  control  and  data 
distribution  or  decentralization  required  is  determined  during  the  Analysis  Phase  that 
precedes  implementation  of  each  functional  block  for  each  MA3COM. 

For  a  detailed  statement  of  required  AFIRMS  DBMS  capabilities,  refer  to  the 
AFIRMS  HQ  USAFE  Database  Specification. 

In  addition  to  the  software  that  comprises  the  AFIRMS  DBMS,  a  software  package 
provides  a  shell  to  the  DBMS  which  accomplishes  the  following: 

a.  Controls  entry  to  and  exit  from  DBMS  functions. 

b.  Provides  a  link  or  connection  between  the  communications  software  and  the 
DBMS. 

c.  Controls  data  retrieval  and  data  update  transactions. 

d.  Generates  a  queue  for  transactions  by  transaction  priority. 

e.  Performs  update  notifications  to  other  sites  for  data  changes  (deletions, 
additions  or  modifications)  in  a  DBMS  file. 

f.  Determines  whether  data  retrieval  and  update  transactions  are  to  be  routed  to 
the  local (functional  area)  database  or  the  central  database. 

g.  Provides  a  link  between  parameter  screen  software  and  the  DBMS  in  order  to 
verify  the  validity  of  parameter  selections. 


3.2.2  Functional  Area  Support  Software.  Each  A  FIR. MS  functional  area  requires  the 
support  software  specified  in  this  section. 


3.2.2. 1  Operating  System.  Functional  Area  operating  svstem  capabilities  are  identical  to 
those  of  the  Central  Node  Module,  identified  in  Section  3.2. 1.1  of  this  subsystem 
specification.  However,  the  following  exception  applies: 

a.  The  FA  operating  system  must  support  at  least  one  interactive  user  in  a 

minimum  configuration  and  up  to  3  concurrent  interactive  users  in  a  maximum 
configuration. 


3.2. 2. 2  Utility  Routines.  FA  utility  routine  requirements  are  the  same  as  those  of  the 
CNM,  identified  in  Section  3. 2.1. 2  of  this  subsystem  specification. 


3.2. 2. 3  Communications  Software.  The  specific  requirements  for  communications 
software  are  determined  during  the  Analysis  Phase  that  precedes  implementation  at  each 
site.  Communications  between  the  CNM  and  the  intelligent  FA  terminals  is 
accommodated  by  communications  protocol(s)  identified  or  confirmed  during  the  Analysis 
Phase  of  each  functional  block  implementation.  The  volume  and  frequency  of  the  various 
information  gateways  by  functional  area  is  presented  in  the  AFIRMS  HQ  USAFE  Database 
Specification  and  Section  4.3.2  of  this  subsystem  specification. 


3.2. 2. 4  Database  Management  System  (DBMS).  Functional  Area  DBMS  and  DBMS  support 
capabilities  are  identical  to  those  of  the  Central  Node  Module,  identified  in  Section 
3.2.2. 1  of  this  subsystem  specification. 

3. 2. 2. 5  Display/Graphics  Software.  AFIRMS  display  screens  are  categorized  by  their 
method  of  display;  graphic,  tabular,  integrated  graphic  and  tabular.  The  tabular  screens 
display  the  data  values  listed  in  table  format,  i.e.,  rows  and  columns.  The  tabular  screens 
may  use  color  to  identify  data  of  like  types  to  help  the  user  assimilate  the  information. 
The  tabular  screens  also  use  colors  to  highlight  a  line  and/or  field  as  a  screen  place 
marker  for  the  user,  or  to  call  attention  to  changes  in  data  currency. 


The  graphic  screens  are  of  three  types:  bar  graph,  line  graph,  and  pictoral  (i.e., 
maps).  These  are  output  screens  only  (i.e.,  they  cannot  be  updated  through  the  display 
screen).  In  addition,  the  bar  graph  screens  have  a  data  value  atop  each  graphed  bar  that 
quantifies  the  analog  display. 

The  display  screen  generation  software  uses  standard  routines  to  generate  these 
screens.  In  summary,  the  generalized  routines  and  particular  features  are: 

a.  Tabular  Screen  Generator  must  possess  the  following  characteristics: 

(1)  Right-justified  numeric  data. 

(2)  Left-justified  alphanumeric  data. 

(3)  Line  highlighter  that  can  be  turned  (i.e.,  toggled)  on  or  off. 

(<*)  Field  highlighter  that  can  be  turned  (i.e.,  toggled)  on  or  off. 

(5)  Full  screen  editor  (for  extensive  data  input  and  editing  capability) 

(6)  Linkable  to  a  special  area  on  the  screen  to  display  remarks  for  a  row  of 
data  (e.g.,  Unit  and  Base  Status  products).  This  requires  that  the  display 
routine  know  where  the  cursor  is  by  page  and  by  row  in  order  to  call  up 
the  correct  set  of  remarks/data. 

(7)  Variable  legend,  either  data-driven  or  user-defined. 

IS)  Blanking  of  repeating  column  data  (selectable). 

IB)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  etc.)  a  row  or 
column  of  data  that  has  changed  from  an  original  or  previous  data  set. 
The  means  oy  which  this  "data  change  indicator"  is  activated  is 
determined  during  the  Vnalvsis  Phase  that  precedes  implementation  of 
particular  functions  which  require  this  capability. 


, )  F  1  icd 


■w  .coring  depending  on  value  of  data  field  (selectable). 

g' a  •  '"able  separately  from  body  of  table. 

v  g;ng  ,  ip,  -  -verse,  down/forward)  as  well  as 

-  entaticn  (i.e.,  virtual  screen)  capability. 

•  .  •••.-■'  *»  t  -  figment  the  paging  feature. 

:  .  tro-  .»  screen  display  without  using  a 


ihihties  to  include  checking  of 
c  c.c  tor-'  it,  as  well  as  upper  and  lower 


(16)  Grid  generation  capability. 

(17)  Title,  subtitle,  and  heading  generation  capability. 

(IS)  Horizontal/vertical  field  count/sum  feature. 

b.  The  Graphic  Screen  Generator  must  possess  the  following  characteristics; 

(1)  Line  Graph  and  Bar  Graph  Generators  share  some  common  capabilities: 


(a)  Variable  legends,  either  data-driven  or  user-defined. 

(b)  Automatic  x-  and  y-axis  scaling. 

(c)  Y-axis  rescaling  after  screen  display  initiated  by  a  function  key. 


(d)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  etc.)  data 
that  has  changed  from  an  original  or  previous  data  set.  The  means 
by  which  this  "data  change  indicator"  is  activated  is  determined 
during  the  Analysis  Phase  that  precedes  each  functional  block 
implementation. 


c. 
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(e)  Field  coloring  depending  on  value  of  data  field  (selectable). 

(f)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

(2)  Map  Maker  capabilities: 

(a)  Linkable  to  a  special  area  on  the  screen  to  display  remarks  or  other 
data  relevant  to  the  display.  This  requires  the  routine  to  know 
where  the  cursor  is  on  the  display  in  order  to  call  up  the  correct 
information. 

(b)  A  coordinate  system  so  Air  Bases  or  other  items  of  interest  can  be 
inserted,  labeled  and  deleted  by  a  nontechnical  user  using  latitude 
and  longitude  or  Geographic  Reference  (GEOREF)  map  coordinates 
(the  positioning  is  reasonably  accurate  with  relation  to  one  another) 

(c)  Coloring  of  the  base  position  according  to  the  dynamic  values  of  a 
set  of  database  variables  (the  color  indicates  a  condition  or  status). 

(d)  A  change  indicator  for  positions  whose  status  or  condition  values 
were  changed. 

(e)  Continuously  variable  software  zoom  (if  not  a  hardware  capability). 

(f)  The  capability  to  generate  and  display  special  symbols. 

(g)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

Display  Screen  Parameter  Software  must  possess  the  following  characteristics: 

( 1)  The  parameter  software  interacts  with  the  AF1RMS  database  when 

necessary,  to  determine,  generate,  and  list  the  appropriate  parameter 

choices  for  the  database  set  requested.  For  example,  if  A  TO  3  (the 
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specified  database  set)  does  not  have  CBU-52  munitions  (a  parameter 
selection)  tasked,  then  the  list  of  choices  for  a  munition  type  (the 
parameter)  will  not  include  CBU-52. 

(2)  The  parameter  software  is  interpretive  in  nature  so  as  to: 

(a)  Ensure  a  consistent  and  well-defined  interface  to  the  database 
transaction  software. 

(b)  Provide  a  flexible  and  user-friendly  mechanism  for  user  selection  of 
alternative  data  sets. 

(c)  Allow  the  user  to  enter  synonymous  parameter  selections;  e.g. 
"YES",  "YE",  "Y",  "OK"  can  all  be  entered  (and  subsequently 
interpreted  by  the  system)  as  an  affirmative,  instead  of  forcing  the 
user  to  precisely  reflect  database  values. 

(3)  The  parameter  software  also  permits  write-in  choices  where  appropriate. 
In  some  instances  it  is  not  possible  or  practical  to  list  all  appropriate 
parameter  selections. 

d.  Function  Keys.  AFIRMS  is  operated  utilizing  a  system  of  menus  and  special 
function  keys.  Some  of  the  product  screen  function  keys  can  be  seen  at  the 
bottom  of  the  display  screens  described  in  the  AFIRMS  Product  Description 
annexes.  As  the  number  of  available  function  keys  is  less  than  the  number  of 
required  keys,  arrays  of  keys  are  utilized  to  overcome  that  problem. 

The  first  array  contains  the  basic  key  functions  needed  for  every  display  screen. 
Except  for  the  Base  Status  Map,  the  graphic  displays  require  only  the  first 
array.  The  tabular  input  screens  require  key  functions  to  add,  delete,  and 
change/edit  data.  A  paging  and/or  scrolling  capability  is  required.  Some  records 
have  sub-records  (e.g.,  a  wing  with  several  munitions  as  in  the  Wing  Resource 
Summary  Product,  a  mission  with  two  aircraft  Mission  Design  Series  and/or 
aircraft  Standard  Conventional  Loads  as  in  the  Tasking  Information  products). 
Therefore,  the  second  array  is  reserved  for  editing  records,  and  the  third  array  is 
reserved  for  editing  sub-records.  Switching  between  arrays  is  done  with  two 
special  function  keys.  An  arrow  on  either  or  both  ends  of  the  function  key  array 
shows  the  user  which  array  is  in  use.  The  required  functions  of  these  function 
keys  are  outlined  in  Table  3-1. 
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Table  3-1 

PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION 


Key  Label 

Function  Description 

1st  Array: 

DISPLAY 

PARAM 

SELECT 

Takes  the  user  back  to  the  parameter  selection  screen.  The  parameter 
choices  the  user  made  to  display  the  product  are  redisplayed. 

LINE 

HIGHLIGHT 

TOGGLE 

Changes  the  state  of  the  Line  Highlighter  toggle.  If  it  is  turned/toggled  OFF, 
the  state  is  changed  to  ON  and  the  Line  Highlighter  appears.  If  it  is  toggled 

ON,  the  state  is  changed  to  OFF  and  the  Line  Highlighter  is  removed  from  the 
tabular  display.  The  function  key  is  not  active  when  a  graphic  screen  is  displayeo. 

HARD 

COPY 

Spawns  a  batch  process  to  print  a  color  copy  of  the  display.  This  key  is 

on  the  1st  array  only  if  the  product  has  a  single  screen  display.  For  multiscreen 

displays,  the  key  is  on  the  2nd  array  with  the  paging  keys. 

TOP 

MENU 

Returns  the  user  to  the  first/top  menu. 

PREVIOUS 

MENU 

Returns  the  user  to  the  menu  from  which  the  product  was  selected. 

HELP 

Interrupts  the  product  display  and  takes  the  user  to  the  HELP  system.  When 
finished  with  the  HELP  screen,  the  user  returns  to  this  display. 

UPDATE 

SCREEN 

Causes  the  system  to  refresh  or  update  the  product  display  using  the 
current  parameter  choices.  Normally  used  with  a  resource  status  product  when 
the  system  notifies  the  user  that  the  status  data  has  been  updated. 

2nd  Array: 

PAGE 

REVERSE 

Page  the  product  in  reverse  order.  It  pages  a  full  or  half  page  at  a  time, 
depending  on  the  paging  option  selected.  It  is  active  only  when  a  tabular  procuct 
is  displayed  and  is  longer  than  one  page  of  display. 

FULL  PG 
HALF  PG 

Changes  the  paging  state  to  FULL  or  HALF  paging,  depending  on  the 
current  state.  The  current  paging  state  is  always  highlighted  or  colored. 

PAGE 

FORWARD 

Causes  the  system  to  page  the  product  forward  in  sequential  order.  It 

pages  a  full  or  half  page  at  a  time,  depending  on  the  paging  option  selected.  It  is 

active  only  as  described  in  PAGE  REVERSE  above. 

CHANGE 

XXXXXX 

DATA 

Permits  editing  of  the  screen  data.  The  'XXXXXX'  is  changed  to  the 
appropriate  term  (such  as  aircraft  or  aircrew)  when  the  product  is 
designed.  Used  only  for  tabular  products.  Pressing  the  function  key  a  second 
time  de-activates  the  CHANGE  mode. 

ADD 

XXXXXX 

DATA 

Permits  the  addition  of  a  record  to  the  database.  Used  only  for  tabular 
products.  Pressing  the  function  key  a  seconc  time  Ge-activates  the 

ADD  mode. 

Table  3-1 


PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION  (Continued) 


Key  Label 

Function  Description 

DELETE 

xxxxxx 

DATA 

Permits  the  deletion  of  a  record  from  the  database.  Used  only  for  tabular 
products.  Pressing  the  function  key  a  second  time  de-activates  the 
DELETE  mode. 

ENTER 

Updates  the  data  base  as  directed  by  the  three  previous  keys  keys 
(CHANGE,  ADD,  and  DELETE  XXXXXX  DATA).  The  ENTER  key  acts  as 
a  confirmation  step  for  the  CHANGE/ADD/DELETE  keys. 

INTERROGATE 

BASE 

Interrogates  the  cursor  position  and  displays  a  box  containing  data  corres¬ 
ponding  to  the  base  displayed  under  the  cursor  (see  Base  Status  Map). 

DELETE 

DATA  BOX 

Deletes  the  box  containing  the  base  data. 

SCALE  UP 

Increases  the  y-axis  scale  of  the  bar  graph  by  approximately  100%  after 
the  screen  is  displayed.  Used  with  bar  graphs  only. 

SCALE  DOWN 

Decreases  the  y-axis  scale  of  the  bar  graph  by  approximately  50 %  after 
the  screen  is  displayed.  Used  with  bar  graphs  only. 

3rd  Array: 

PAGE 

REVERSE 

Page  the  product  in  reverse  order.  It  pages  a  full  or  half  page  at  a  time, 
depending  on  the  paging  option  selected.  It  is  active  only  when  a  tabular 
product  is  displayed  and  is  longer  than  one  page  of  display. 

FULL  PG 

HALF  PG 

Changes  the  paging  state  to  FULL  or  HALF  paging,  depending  on  the 
current  state.  The  current  paging  state  is  always  highlighted  or  colored. 

PAGE 

FORWARD 

Causes  the  system  to  page  the  product  forward  in  sequential  order.  It 
pages  a  full  or  half  page  at  a  time,  depending  on  the  paging  option 
selected.  It  is  active  only  as  described  in  PAGE  REVERSE  above. 

CHANGE 

XXXXXX 

DATA 

Same  as  CHANGE  XXXXXX  DATA  key  above  except  only  sub-record  data 
is  changed.  The  system  prevents  changes  to  record  keys  /data. 

ADD 

XXXXXX 

DATA 

Same  as  ADD  XXXXXX  DATA  key  above  except  able  to  add  sub-records 
only. 

DELETE 

XXXXXX 

DATA 

Same  as  DELETE  XXXXXX  DATA  key  above  except  able  to  delete 
sub-records  only. 

ENTER 

Updates  the  data  base  as  directed  by  the  three  previous  keys 
(CHANGE,  ADD,  and  DELETE  XXXXXX  DATA).  The  ENTER  key  acts  as 
a  confirmation  step  for  the  CHANGE/ADD/DELETE  keys. 

3.2«2.6  User  Interface  Software.  The  primary  functions  of  this  software 
subsystem  are  as  follows: 


a.  It  provides  the  AFIRMS  user's  sole  view  of  the  AFIRMS  system. 

b.  It  serves  as  the  link  by  which  the  AFIRMS  user's  requests  are 
translated  into  internally  recognized  system  functions,  validated, 
and  subsequently  performed  by  the  system. 


The  software  providing  user  interface  to  the  AFIRMS  system  possesses  the 
following  characteristics: 

a.  Menu  driven  with  a  command  language  available  to  provide  software 
capabilities  for  experienced  users. 

b.  Consistent  menu  displays  and  underlying  definitions. 

c.  User-friendly. 

d.  Fault- tolerant. 

e.  Menu  paging  or  scrolling. 

f.  Help  available  at  all  levels  of  user/system  interaction. 

g.  Allows  for  multiple  access  paths  to  all  user  functions  (via 
functional  area  workstation  groupings,  alphabetical  lists,  logically 
related  system  functions,  etc.) 

h.  Provides  functionality  to  accept  specified  user  parameters  which 
limit  information  returned  for  screen  data  retrieval  requests. 

i.  Provides  functionality  to  allow  interactive  "through  the  display 
screen"  updates  to  the  AFIRMS  database  (as  discussed  in  section 
3. 2. 2. 5  of  this  subsystem  specification). 

j.  Detects  and  automatically  logs  off  terminals  which  have  been  inactive 
for  an  operator  definable  period  of  time.  This  time  is  determined 
and  set  by  the  system  operator. 


3.3  Interfaces.  AFIRMS  avoids  data  redundancy  when  possible;  however,  some 
redundancy  is  required  for  deployment  and  response  time  requirements.  AFIRMS 
where  possible,  also  maximizes  the  use  of  USAF  and  MAJGOM-umque  data  system 
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(as  well  as  other  suitable  DoD  Automated  Data  Processing  Systems  (ADPSs))  to 
provide  AFIRMS  information.  This  paragraph  provides  a  description  of  the  HQ 
USAFE  subsystem  intrasite  interfaces.  Interfaces  to  the  HQ  USAF  and  wing 
subsystems,  as  well  as  interfaces  to  external  (e.g.,  USAF,  DoD)  automated 
systems  are  discussed  in  the  AFIRMS  System  Specification. 


The  HO  I'SAFE  subsystem  interfaces  with  wing  and  HO  L’SAF  subsystems  through 
cornputer-to-computer  network  software  products.  These  products  link  various  operating 
systems  and  provide  the  functionality  required  to  effect  information  flows  between 
A  FIR  MS  subsystems. 

As  AFIRMS  intends  to  host  on  existing  hardware  and  equipments  as  much  as  possible, 
the  specific  protocols  to  be  used  are  largely  dependent  upon  existing  and/or  planned  Air 
Force  ADPSs.  Thus,  they  are  determined  or  confirmed  during  the  Analysis  Phase  that 
precedes  implementation  of  each  functional  block. 

AFIRMS  is  developed  to  take  advantage  of  currently  existing  systems  that  already 
provide  accurate  data  collection.  It  is  also  designed  to  take  advantage  of  systems  that 
produce  capability  assessments  using  a  subset  of  the  resources  AFIRMS  ultimately  uses  to 
produce  its  capability  assessments.  In  order  to  handle  interfaces  with  future  developing 
systems,  AFIR  MS  is  designed  modularly  with  generic  data  gateway  interfaces.  As  these 
new  systems  are  implement'll,  they  can  easily  be  interfaced  with  AFIRMS.  These  generic 
interfaces  apply  to  communications  networks  as  well  as  data  systems. 

AFIRMS  is  data  collection  intensive.  However,  AFIRMS  attempts  to  minimize 
duplication  of  the  collection  of  any  data  that  is  already  being  collected  by  another  system 
ie.g..  munitions  data  collected  by  Combat  Ammunition  System  (CAS)).  In  addition, 
AFIRMS  does  not  compute  an  assessment  that  is  already  suitably  available  in  another 
system  (e.g.,  spares  analysis  computed  by  UeaKon  System  Management  Information 
'Astern  (’A  s\US)). 


3,3.1  AFIRMS  Intrasite  Interfaces.  The  transactions  that  occur  within  a  particular 
\FIRMs  site  require  tnrec  types  of  interface  specifications: 

a.  Intrasite  Transaction  Header.  This  interface  specification  defines  the  format 
ot  the  information  required  to  transmit  any  transaction  to/from  the  CNM 
from,  to  anv  functional  area  workstation. 

Appendix  A  pros  ides  the  detailed  specification  of  the  information  i  ontained  in 
this  deader  irterf ace. 

.  Htsplav  si  re>m  Interfaces.  These  interface  specifications  define  the  format  of 
t:  e  data  that  is  retrieved  on  behalf  of  the  functional  user  in  accordance  with 
ms  her  mnut  r>.»ran  etcrs  and  aibsecuentlv  transmitted  to  the  functional  area. 
For"  of  these  interface  specifications  also  requires  an  Intrasite  Transaction 


Table  3-2  provides  a  cross-reference  between  the  AFIRMS  output  reports  set 
forth  in  Section  4.3.2  of  this  subsystem  specification  and  the  AFIRMS  internal 
interface  specifications  provided  in  Appendix  B. 

c.  Data  I'pdate  and  Retrieval  Transaction  Interfaces. 

The  logical  data  flow  for  data  update  and  retrieval  transactions  is  provided  in 
Tables  3-3  and  3-4  respectively. 

Tables  3-5  and  3-6  provide  the  interface  specifications  for  the  data  update  and 
data  retrieval  requests,  respectively.  Each  of  these  requests  also  requires  an 
Intrasite  Transaction  header  as  defined  above. 


3  34  01 


3-; 


Table  3-2 


AFIRMS  OUTPUT  REPORT 


(Cross-Reference  to  Appendix  B) 


Screen  Title 

Interface 

Spec.  Appendix 
Cross-Reference 

Aircraft  and  Mission  Tasking  Details 

APIB/S 

Aircraft  Spares  Support  Capability 

APIB/S 

Aircraft  Tasking 

B-2 

Attrition  Statistics 

APIB/S 

Attrition  T  rends 

APIB/S 

Base  Fuels  Capability 

B-2 

Base  Status  (Input) 

B-l 

Base  Status  (Output) 

B-l 

Capability  Perspective 

B-2 

Communications  Support  Status 

APIB/S 

Dollars  to  Readiness  -  Comparisons 

B-6 

Dollars  to  Readiness  Associations 

B-6 

Dollars  to  Readiness  -  Resource  Perspective 

B-6 

Individual  Resource  Capability 

B-2 

Integrated  Capability 

B-2 

MICAP  Forecast 

APIB/S 

Mission  Area  Tasking 

APIB/S 

Mission  Profile  Definition 

B-l 

Mission  Tasking 

APIB/S 

Munitions  Capability 

B-2 

Munitions  Status 

B-l 

Munitions  Substitution  Sortie  Capability 

APIB/S 

Munitions  Substitution  Sortie  Requirement 

APIB/S 

OPlan/OPORD  Associations 

B-l 

Order  Assignments 

B-l 

Process  Status 

B-l 

Resource  Reallocation 

B-l 

Resource  Unit  Price 

B-l 

Status  Map 

B-3 

Unit  Status  (Input) 

B-l 

Unit  Status  (Output) 

B-l 

War  Mobilization  Plan 

B-l 

Wing  Flying  Day 

B-l 

Wing  Operations  Rates 

B-l 

Wing  Resource  Summary 

B-l 

Wing  Resupply  Schedule 

B-l 
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DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation) 


User  logs  onto  FAW  by  entering  username  and  password. 

If  username/password  combination  is  invalid,  then 

The  FAW  keeps  track  of  the  number  of  consecutive  times  this  occurs,  as  well  as  the 
invalid  information. 

If  invalid  information  has  been  entered  three  times  in  a  row,  then 

FAW  logically  locks  the  terminal  from  further  use  by  saving  the  information  on 
the  disk  and  indicating  that  state. 

FAW  generates  a  siren-like  sound  indicating  the  security  violation. 

FAW  displays  the  security  violation  screen. 

FAW  sends  to  the  ACNM  (if  possible)  a  security  message  indicating  the  problem. 
The  ACNM  notifies  the  security  officer  via  three  ways: 

(1)  Sends  a  message  directly  to  his/her  terminal  if  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardcopy  device. 

Else 

FAW  gives  user  another  chance  to  logon  properly. 

Endif 

Else  [valid  user  logon  has  occurred  on  the  FAW] 

FAW  attempts  to  logon  to  the  ACNM  by  passing  the  username/password  entered. 

The  ACNM  performs  security  checks. 

If  a  security  violation  has  been  detected,  then 

ACNM  logically  locks  the  terminal  port  from  further  use  by  saving  information 
on 

the  disk  and  indicating  that  state. 

The  ACNM  notifies  the  security  officer  via  three  ways: 

(1)  Sends  a  message  directly  to  his/her  terminal  if  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardcopy  device. 

The  ACNM  tells  the  FAW  of  the  security  violation. 

Else  [valid  user  logon  has  occurred  on  the  ACNM] 

AFIRMS  processes  are  started  that  run  on  the  user's  behalf. 

If  there  is  no  problem  starting  these  processes,  then 

AFIRMS  code  and  data  needed  for  the  user  are  downloaded. 


user. 


If  all  necessary  data  and  code  reach  the  FAW  successfully,  then 

The  ACNM  gets  ready  for  requests  from  the  FAW  on  behalf  of  the 

The  ACNM  tells  the  FAW  that  fact. 

Else 

There  is  a  problem. 

Endif 


Endif 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation)  (Continued) 


If  there  is  a  problem  on  the  ACNM,  then 

The  ACMN  informs  the  FAW  of  the  problem. 

The  ACNM  logs  the  user  off  AFIRMS. 

The  FAW  notifies  the  user  of  the  problem. 

If  a  local  database  for  this  user  exists  from  a  previous  logon,  then 

the  user  is  allowed  to  make  requests  of  his/her  local  database  only. 

Else 

The  FAW  notifies  the  user  of  the  problem. 

The  FAW  logs  the  user  off  AFIRMS. 

Endif 

Endif 

Endif 

Endif 

[CNM  checks  for  data  stored  on  behalf  of  the  user  on  non-volatile  random  access  medium.] 
If  ACNM  finds  data  destined  for  the  user,  then 
ACNM  sends  FAW  user  data  summary. 

Endif 

ACNM  sends  FAW  the  currently  available  C PU/processing  power  for  each  CNM. 

FAW  notifies  user  of  data  stored  on  his/her  behalf  (e.g.,  previous  request,  mail). 

If  user  chooses  details  of  his/her  CNM  data,  then 
FAW  displays  user  data  summary. 

[User  selects  which  data  he/she  wishes  to  view/delete.] 

Endif 

If  user  wishes  to  view/delete  a  dataset,  then 

If  ACNM  can  be  talked  to  via  normal  communications  link  or  dial-up,  then 
The  view/delete  request  is  transmitted  to  the  ACNM. 

Else 

The  user  is  notified  that  there  is  a  problem. 

The  user  is  asked  to  make  another  request. 

Endif 

r*  _  :  c 


Bl 


TABLE  3- 3a 

DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation)  (Continued) 


FAW  user  requests  screen  for  viewing  via  FAW  MMI. 

[FAW  database  is  checked  for  required  data.] 

If  all  data  exists  (is  resident)  locally,  then 

FAW  software  determines  if  the  response  time  would  be  taster  by  allowing  a  CNM  to 
perform  the  request. 

If  processing  is  faster  on  the  CNM,  then 
The  request  is  transmitted  to  the  ACNM. 

Else  [processing  is  faster  locally] 

The  FAW  handles  the  request  locally. 

Endif 

Else  [some  or  all  of  the  data  exists  elsewhere] 

The  user  is  informed  that  his/her  request  requires  access  to  the  CNM's  database. 

The  user  is  asked  for  confirmation  of  the  request. 

If  the  user  confirms  the  request,  then 

If  the  ACNM  can  be  talked  to  via  normal  link  or  dial-up,  then 
The  request  is  transmitted  to  the  ACNM. 

Else 

The  user  is  notified  there  is  a  problem. 

The  user  is  requested  to  make  another  screen  selection. 

Endif 

Else  [the  user  didn't  confirm  the  request] 

The  user  is  requested  to  make  another  screen  selection. 

Endif 

Endif 


Acronym  Definitions 


ACNM  -  the  CNM  directly  attached  to  the  user's  FAW 

AFAW  -  all  functional  area  workstations  attached  to  an  ACNM 

CNM  -  central  node  module/manager 

FAW  -  functional  area  workstation 

MMI  -  man-machine  interface 

NCNM  -  CNM  that  the  user  is  newlv  attached  to  (assuming  he  logged  off  while  his 
request  was  being  processed) 

NFAW  -  newly  logged-on  to  FAW 

OCNM  -  original  CNM  that  received  a  FAW  request 

OF  AW  -  original  FAW  that  made  a  request 

PCNM  -  the  CNM  that  actually  performed  the  FAW  request 
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DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager) 


The  ACNM  receives  a  FAVl  request  for  data  retrieval. 

[The  OCNM  determines  which  CNM  can  best  process  the  request.] 

If  the  request  should  be  handled  by  a  "different"  CNM,  then 

The  request  is  transmitted  to  the  CNM  that  can  best  handle  it. 

Endif 

If  there  are  requests  currently  queued,  then 

[A  separate  queue  is  maintained  for  updates.  It  is  always  serviced  before  the  query  queue 
in  order  to  minimize  database  conflicts.] 

The  request  is  queued  according  to  priority  using  a  FIFO  algorithm. 

As  requests  are  completed,  the  next  request  performed  is  the  one  at  the  top  of  the 
highest  priority  queue  with  a  request  currently  queued. 

Else  [there  are  no  other  requests  queued] 

The  request  is  performed  immediately. 

The  PCNM  transmits  to  each  AFAW  and  all  other  CNMs  its  currently  available 
(unused)  CPU /processing  power. 

Endif 

The  CNM  that  processes  the  request  transmits  to  each  attached  FA  and  all  other  CNMs 
its  currently  available  processing  power.  Each  of  the  "other"  CNMs  also  transmits  this 
processing  capability  to  its  FAWs. 

[tthen  an  interactive  request  is  completed,  the  results  are  sent  back  to  the  requesting 
user.] 

If  the  request  was  handled  by  other  than  the  OCNM,  then 

[First  a  check  is  made  to  see  if  the  user  is  still  logged  onto  any  of  the 
OCNM's  FAWs.] 

If  the  PCNM  can  talk  to  the  OCNM,  then 

The  PCNM  sends  a  "check  if  the  user  is  still  logged  on"  request  to  the  OCNM. 

The  OCNM  sends  a  response  to  the  PCNM. 

If  the  user  is  still  logged  onto  the  OCNM,  then 
The  PCNM  transmits  the  results  to  the  OCNM. 

Elseif  the  user  is  logged  onto  any  of  the  PCNM's  FAWs,  then 
The  PCNM  transmits  the  results  to  the  user's  NFAW. 
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DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


Elseif  the  PCNM  can  talk  to  the  other  CN  Vis,  then 

The  PCNM  sends  a  "check  if  user  is  still  logged  on"  reauest  to  each  of  the  other 
CNMs  in  sequence  to  determine  if  the  user  is  logged  onto  any  other  CNM's  FAWs. 

If  the  user  is  not  logged  onto  the  system,  then 
The  PCNM  transmits  the  results  to  the  OCNV1. 

The  OCNM  saves  the  results  on  a  non-volatile,  random  access  medium  for 
later  use. 

Else 

The  PCNM  transmits  an  "asynchronous  event"  message  to  the  CNM  which 
is  attached  to  the  NFAW'  the  user  is  logged  onto. 

That  CNM  then  transmits  the  message  to  the  user's  NFAW. 

Endif 

Else  [the  communications  links  between  the  CNMs  not  working] 

The  PCNM  saves  the  results  on  non-volatile,  random  access  medium  for  later  use. 
Endif 

Else  [communications  link  between  the  PCNM  and  the  OCNM  not  working] 

If  the  user  is  logged  onto  any  of  the  PCNM's  FAWs,  then 
The  PCNM  transmits  the  results  to  the  user's  NFAW. 

Else 

The  PCNM  saves  the  results  on  non-volatile,  random  access  medium  for  later  use. 
Endif 
Endif 
Endif 

If  the  user  is  logged  onto  any  FAWs  when  his/her  request  completes,  then 

The  ACNM  transmits  the  results  to  the  user's  FAW  regardless  of  whether  the  user 
is  logged  onto  the  OFAW  from  which  the  request  was  made,  or  a  NFAW. 

Endif 

The  PCNM  must  transmit  to  each  attached  FA  and  all  other  CNMs  its  available  CPU/ 
processing  capability.  This  capability  is  used  by: 

(1)  The  FAWs  to  determine  if  a  CNM  can  handle  a  request  faster,  and 

(2)  The  CNMs  to  determine  which  CNM  can  handle  a  request  faster. 


Acronym  Definitions 

ACNM  -  the  CNM  directly  attached  to  the  user's  FAW 
AFAW  -  all  functional  area  workstations  attached  to  an  ACNM 
CNM  -  central  node  module/manager 
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TABLE  3-3b 


FA  VI 
MMI 
NCNM 

NFAW 
OCNM 
OF  AW 
PCNM 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


-  functional  area  workstation 

-  man-machine  interface 

-  CNM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 

request  was  being  processed) 

-  newly  logged-onto  FAW 

-  original  CNM  that  received  a  FAW  request 

-  original  FAW  that  made  a  request 

-  the  CNM  that  actually  performed  the  FAW  request 


After  reviewing  the  retrieved  data,  the  user  updates  a  record. 

The  editor  does  not  allow  the  user  to  change  any  field  that  he/she  does  not  have  privilege  for. 
The  OFAW  sends  the  updated  record  (including  its  keys)  to  the  ACNM. 

The  OF  AW  also  updates  its  local  database.  A  copy  of  the  "before"  and  "after"  database 
record  images  is  saved  in  case  the  update  must  be  backed  out. 

[Note:  The  user  is  not  prevented  from  making  further  requests  of  AFIRMS  at  this  point.  All 
messages  from  the  ACNM  occur  asynchronously.  The  user  is  notified  each  time 
asynchronous  messages  occur.  At  that  point,  he/she  can  request  a  display  containing  a  list 
of  all  asynchronous  events  pertaining  to  him/her.  This  display  is  a  temporary  "window" 
which  is  used  only  for  viewing  any  asynchronous  events.  It  cannot  be  used  for  any  screen 
which  can  be  requested  via  the  normal  screen  selection  list.  This  wind^.v  can  also  be  looked 
at  via  the  normal  screen  selection  list.  Viewing  of  this  screen  does  not  in  any  way  destroy 
tne  state  of  the  screen  the  user  was  viewing  prior  to  looking  at  the  window.  That  is,  after 
the  user  has  completed  viewing  the  window,  the  next  screen  seen  is  the  one  the  user  was 
viewing  at  the  time  he/she  requested  to  look  at  the  window,  restored  to  its  original  state.] 

For  all  other  FA  Vi’s  receiving  the  changed  information  from  their  ACNM, 

The  local  database  is  updated  with  the  changed  information. 

(f  the  user  is  currently  looking  at  the  changed  information,  then 
The  FAW  indicates  to  the  user  that  a  change  has  occurred. 

The  user  can  then  look  at  the  screen  via  a  window  that  contains  all 
asynchronous  events,  if  desired. 

Endif 

Endfor 

If  the  OFAW  receives  a  security  violation  message  from  the  ACNM,  then 

The  OFAW  logically  locks  the  terminal  from  further  use  by  saving  the  information  on 

the  disk  and  indicating  that  state. 

The  OFAW  generates  a  siren-like  sound  indicating  the  security  violation. 

The  OFAW  displays  the  security  violation  screen. 

The  OFAW  backs  out  the  update  that  was  attempted. 

The  OFAW  deletes  the  "before"  and  "after"  database  record  images. 

Elseif  the  OFAW  cannot  send  a  message  to  its  ACNM  because  of  communications 
problems,  then 

The  OFAW  backs  out  the  update  that  was  made  previously. 

The  OFAW  deletes  the  "before"  and  "after"  database  record  images. 

The  OFAW  allows  the  user  to  continue  making  other  requests. 


Elseif  the  OFAW  receives  a  processing  error  message  from  the  ACNM,  then 

The  ACNM  saves  the  update  information  on  non-volatile  random  access  medium  for 
later  use  in  attempting  to  update  the  cental  database. 

The  OFAW  deletes  the  before  and  after  database  record  images. 

Endif 
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TABLE  3-4a 


Acrony 

ACNM 

AFAW 

CNM 

FAW 

MMI 

NCNM 

NF  AW 

OCNM 

OFAW 

PCNM 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Functional  Area  Workstation) 


Definitions 


-  the  CNM  directly  attached  to  the  user's  FAW 

-  all  functional  area  workstations  attached  to  an  ACNM 

-  central  node  module/manager 

-  functional  area  workstation 

-  man-machine  interface 

-  NM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 

request  was  being  processed) 

-  newly  logged-onto  FAW 

-  original  CNM  that  received  a  FAW  request 

-  original  FAW  that  made  a  request 

-  the  CNM  that  actually  performed  the  FAW  request 


TABLE  3-4b 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Central  Node  Manager) 

The  ACNM  receives  an  OFAW  update  request. 

[The  OCNM  determines  whether  the  update  request  should  be  processed  immediately 
or  not.] 

If  there  are  other  update  requests  in  the  update  queue,  then 

The  update  request  is  queued  at  the  end  of  the  update  queue. 

As  update  requests  are  completed,  the  request  that  is  at  the  top  of  the  update  queue 
is  performed. 

Endif 

[The  OCNM  performs  a  security  check  to  make  sure  the  user  is  allowed  to  make  the 
update  to  the  database.] 

If  the  user  is  not  allowed  to  make  the  update  [a  security  violation  has  occurred]  then 
The  OCNM  informs  the  FAW  of  the  problem. 

The  OCNM  notifies  the  security  officer  via  three  ways: 

(1)  Sends  a  message  directly  to  his/her  terminal  if  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardcopy  device. 

Else  [the  user  is  allowed  to  make  the  update] 

The  OCNM  attempts  to  update  the  central  database. 

If  the  user  making  the  update  request  is  still  logged  onto  the  OFAW',  then 
The  OCNM  sends  the  update  status  back  to  the  OFAW. 

Else 

The  OCNM  saves  the  update  status  on  non-volatile  random  access  medium  for 
later  use. 

Endif 

[The  OCNM  dete  rmines  whether  other  CNMs  need  that  update  information.] 

If  other  CNMs  need  the  update  information,  then 

It  is  sent  to  them.  In  addition  to  the  changed  information,  the  time/date  of  the 
update,  as  well  as  the  username  of  the  person  that  made  the  change,  are  sent. 
Endif 

All  CNMs  that  receive  updated  information  must  send  those  changes  to  each  of  their 
AFAWs  that  currently  have  a  local  database  containing  that  record. 

[Data  consistency  checks  are  made.] 

If  other  data  within  the  central  database  is  inconsistent  with  the  newly  updated 
information,  then 

That  data  is  made  consistent  by: 

(1)  intelligent  software,  or 

12)  requesting  the  user  to  make  other  information  consistent:  otherwise  the  original 
change  is  backed  out  and  all  FAWs  originally  receiving  that  change  are  notified. 

Endif 

Endif 
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TABLE  3-4b 


DESCRIPTION  OF  DATA  FLO1* 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Central  Note  Manager)  (Continued) 


Acronym  Definitions 


ACNM 
A  F  A  W 
CNM 
FA  VI 
MMI 
NCNM 

NFAW 

OCNM 

OFAW 

PCNM 


the  CNM  directly  attached  to  the  user's  FAW 

all  functional  area  workstations  attached  to  an  ACNM 

central  node  module/manager 

functional  area  workstation 

man-machine  interface 

N.M  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 
request  was  being  processed) 
newly  logged-onto  FAW 
original  CNM  that  received  a  FAW  request 
original  FA^  that  made  a  request 
the  CNM  that  actually  performed  the  FAW  request 


Table  3-3 


CNM  DATA  RETRIEVAL  REQUEST  INTERFACE  SPECIFICATION 


Date:  31-Ma\-H$5 


layout  is  as  follows: 


Repeats  <//  of  parameters  to  follow  >times 


Field  Name _ 

Screen  number  requested 
Number  of  parameters  to  follow 
Parameter  number 
Parameter  selection  number 
Length  of  parameter  value 
Parameter  value 


Note:  Each  field  '■vhose  lengtn  is  reoresents  a  variable  length  field.  Only  these 
fields  are  orececec  a  Z-ov  *.e  .ergtr  aescr.ctcr  r.e.c. 


INM  Data  Retrieval  Request 
Interface  Specification 


The  CNM  Data  Retrieval  Request  buffer 


Table  3-6 


CNM  DATA  UPDATE  REQUEST  INTERFACE  SPECIFICATION 


CWl  Update  Request  Interface  Specification  Date:  3  l-\1ay- 19S3 
The  C.VM  Update  Request  buffer  layout  is  as  fellows: 


I — Repeats  for  the  number  of  keys  for  this  screen 


Screen  It 
for  update 


Column  It 

Length  of 

Key 

for  screen 

key  value 

value 

I —  Repeats  It  of  changes  to  follow!  times 


it  of  changes 
to  follow 


Column  It  for 

Length  of 

New 

screen  to  modify 

new'  value 

value 

V  te Id  Name _  Field  Length 


Screen  It  for  update  3 

Column  It  for  screen  2 

Length  of  key  value  2 

Key  value  ? 

>t  of  changes  to  follow  3 

Column  It  for  screen  to  modify  2 

Length  of  new  value  2 

New  value  ? 


Note:  Each  field  whose  length  is  represents  a  variable  length  field.  Only  these 
fields  are  preceded  oy  a  2-byte  length  descriptor  field. 


3.4  Security.  The  HO  '-'SAFE  operational  AFIRMS  ADPS  processes  data  up  to  a 
classification  level  of  TOP  SECRET.  HO  L'SAFE  personnel  accessing  AFIRMS  must  have 
clearances  and  a  need-to-know  at  the  highest  classification  level  of  data  being  processed 
or  stored  in  the  facility.  Although  sites  at  the  wing  level  operate  in  the  Controlled 
Security  Mode,  HO  ESAFE  (M  A3COM  Headquarters)  and  the  HO  L'SAF  sites  operate  in 
the  System  High  Security  Mode.  This  is  accomplished  by  utilizing  a  combination  of  the 
following  security  measures: 

a.  Pers  nnel  Security.  All  personnel  having  access  to  MAJCOM  and  HO  L'SAF 
AF1RMS  facilities  and/or  data  have  a  security  clearance  equal  to  the  highest 
level  of  classification  being  processed,  stored,  or  displayed.  At  all  AF1RMS 
sites,  each  user's  identity  is  positively  established  via  user  IDs  and  logon 
passwords  (terminal  display  of  which  is  suppressed),  which  are  to 
authenticate/verify  AFIRMS  users'  identities  and  their  corresponding  access 
privileges.  AFIRMS  provides  a  capability  to  prevent  unauthorized  users  from 
executing  a  protected  program  or  senes  of  programs. 

A  personnel  security  program  is  implemented  for  the  AFIRMS  program  in 
accordance  with  the  provisions  of  DoD  Regulation  5200.2/AFR  205-32  L'SAF 
Personnel  Security  Program.  Personnel  access  controls  must  be  implemented 
for  the  AFIRMS  central  computer  facilities  and  remote  terminal  areas. 

U)  Central  Computer  Facility.  Strict  personnel  access  controls  are 

implemented  to  ensure  that  the  only  personnel  admitted  are  those  who 
require  access  to  the  central  computer  facility  and  possess  a  security 
clearance  at  least  equal  to  the  highest  classification  of  information  being 
processed  or  openly  stored  at  the  facility. 

(2)  Remote  Terminal  Area(s).  Authorization  for  access  to,  and  the  use  of, 
remote  terminal  devices  is  to  be  based  on  an  individual's  duties,  his/her 
need  to  use  the  terminal,  and  possession  of  a  security  clearance  of  the 
required  level. 

b.  Physical  Security.  Measures  are  taken  to  ensure  external  protection  for 
AFIRMS  against  unauthorized  access  to  the  central  computer  facility,  to  the 
system  from  remote  terminals,  and  to  data  storage  media. 

( 1)  Central  Computer  Facility.  Central  computer  facility  physical  security 
must  meet  the  requirements  established  for  the  highest  classification  and 
all  sensitivity  categories  of  data  that  are  either  resident  in  the  ADPS  or 
openly  stored. 

(2)  Remote  Terminal  Area(s).  Physical  security  measures  at  remote  sites 
must  fulfill  the  minimum  requirements  for  the  highest  classification  of 
information  accessed  from  or  stored  at  the  site. 

Hardware  Security.  AFIRMS  system  hardware  meets  all  of  the  provisions 
recommended  in  DoD  5200. 2SW,  ADP  Security  Manual  for  hardware  security 


Software  Security.  The  operating  systems  selected  for  use  meets  the  general 
software  security  requirements  stated  in  DoD  5200. 2SM.  In  addition  to  the 
security  protection  features  contained  in  the  operating  systems,  a  combination 
of  system  and  application  software  protection  features  are  utilized  to  provide 
the  following  security  protection  to  comply  with  applicable  DoD  and  Air  Force 
security  policies. 

(1)  Access  Control  to  prevent  unauthorized  entry  to  systems,  files  and 
programs.  Wings  cannot  query  HQ  b'SAFE  (M AOCOM-level)  data. 
Information  flow  is  one-way  (upwards)  from  wings  to  HQ  USAFE. 

(2)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files. 

(3)  Error  Surveillance  and  Alerts  to  recognize,  record  and  indicate  misuse  of 
the  system. 

(4)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files.  An 
automated  audit  trail  will  show:  access  made  to  files;  how,  and  from 
where  the  access  was  initiated;  the  identity  of  the  person  or  process  that 
initiated  the  access;  and  all  unauthorized  attempts. 

(5)  User  Monitoring  and  Isolation  to  ensure  the  user  has  access  to  only  the 
system  information  to  which  he  is  entitled. 

System  Stability.  AH  AFIRMS  components  operate  so  that  one  can 
automatically  or  administratively  detect  and  report  system  hardware  and 
software  malfunctions  in  time  to  prevent  unauthorized  disclosure. 

Data  Integrity.  Each  database,  file,  and  data  set/element  is  identified  with  an 
origin,  use,  and  an  explicitly  defined  set  of  access  controls.  These  access 
controls  are  based  on  classification,  sensitivity,  user  clearance,  and  established 
need-to-know. 

National  Bureau  of  Standards  (NBS)  or  National  Security  Agency  (N5A) 
approved  data  encryption  devices  may  be  required  for  transmission  of  sensitive 
unclassified  data  depending  on  the  nature  of  the  data. 

Emanations  Security  (EMSEC).  ADP  and  communications  equipment  utilized  to 
process  classified  material  at  AFIRMS  sites  are  TEMPEST  approved.  All 
devices  that  are  not  TEMPEST  approved  will  be  tested  and  approved  for 
placement  in  the  ADP  facilities  in  such  a  manner  as  to  control  compromising 
emanations.  All  equipments  are  installed  1AW  the  guidelines  stated  in  NAC5IM 
5203. 

Procedural  Security.  Security  operating  procedures  meet  the  requirements  of 
AFR  205-1  and  205-16  and  include  the  following: 

(1)  System  Access  Controls 

(2)  File  Access  Controls 

(3)  Personnel  Access  Controls 
(**)  Security  Markings 


(5)  Protecting  Classifies  C  .to 

(6)  Physical  Security 

(7)  Protection  of  Residual  Information 
(S)  Declassification  Guidelines 


3.5  Controls.  The  AFIRMS  system  requires  integrated  control  functions  which  operate 
at  system  levels  independent  of  stated  AFIRMS  operational  functionality.  These  functions 
are  implemented  and  utilized  in  such  a  way  as  to  minimize  their  impact  on  AFIRMS 
execution. 

Control  functions  are  logically  separated  into  two  functional  categories; 
Svstem/Operations  Management  Controls,  and  Intrasite  Access  and  Data  Flow  Controls. 

3.5.1  System/Qperations  Management  Controls.  These  controls  incorporate  the  following 
functions: 


a.  The  apolication  of  software  monitoring  and  diagnostic  utilities. 

b.  The  application  of  hardware  monitoring  and  diagnostic  utilities. 

c.  The  ability  to  start,  stop,  and  restart  AFIRMS  system  and  communications 
processes,  including  upper-level  control  of  network  performance. 

d.  The  ability  to  alter  AFIRMS  subsystem  runtime  parameters  dynamically  (e.g., 
process  priorities,  operating  system  parameters,  etc.) 

3.5.2  Intrasite  Access  and  Data  Flow  Controls.  These  functions  address  control 
reauirements  imposed  by  security  and  data  integrity  issues.  They  also  assist  in  supporting 
downgraded  operational  modes.  These  functions  include: 

a.  Dynamic  imposition  of  limitations/new  priorities  on  intrasite  data 
communications  to  and/or  from  specific  functional  areas. 

o.  Dynamic  lirmtations/alterations  of  data  access  and/or  data  modification 
authorizations  for  specific  functional  areas. 


SECTION  4.  DESIGN  DETAILS 


4.1  General  Operating  Procedures.  After  AFIRMS  is  installed,  user/operator 
manuals  guide  system  operation.  The  user/operator  manuals  contain 
instructions  on  how  to  turn  equipment  on  and  off,  as  well  as  clear,  concise 
instructions  for  the  operation  of  AFIRMS.  Operating  procedures  for  both  the 
system  software,  hardware,  and  functional  products  are  provided  as  a 
combination  of  vendor-provided  documents  and  AFIRMS  user  manuals.  The 
vendor-supplied  documents  detail  hardware  and  system  software  procedures  while 
AFIRMS  user  manuals  detail  functional  product  procedures  including 
communications  and  security.  The  manuals  are  written  in  sufficient  detail  to 
enable  the  system  user  to  respond  to  most  situations  he/she  may  encounter. 

The  specific  requirements  for  AFIRMS  user/operator  manuals  are  determined 
during  the  in-depth  analysis  that  precedes  implementation  at  each  AFIRMS  site. 


4.1.1  System  Start.  Restart,  and  Stop  Times.  Maximum  system  start,  restart, 
and  stop  times  are  provided  below.  AFIRMS  hardware  must  accommodate  these 
times.  All  specified  times  are  non-data  communications  related;  i.e.,  they  do 
not  include  the  amount  of  time  that  may  be  required  to  transfer  additional 
required  data  from  the  CN  to  the  FA  upon  system  startup.  Data  communications 
times  are  dependent  upon  the  data  distributions  at  each  AFIRMS  site.  These 
times  presume  a  booted  and  ready  Central  Processing  Unit  (CPU);  that  is  to 
say,  times  exclude  host  machine  power  up  and  initial  bootstrap. 


Central  Node  Functional  Area 

System 
System 
S  ystem 


Start 

Restart* 

Stop  (Down) 


45  seconds 
90  seconds 
90  seconds 


90  seconds 
180  seconds 
180  seconds 


*  Precise  definition  and  features  of  the  System  Restart  are  reviewed  and 
determined  during  the  analysis  phase  that  precedes  implementation  at  each 
site . 
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4.2  Wing  Subsystem  Logical  Flow.  AFIRMS  logical  and  intrasite  information 
flow  is  shown  in  Figures  4-1  and  4-2,  respectively.  Squadrons  are  linked 
hierarchically  to  a  wing  which  may  be  linked  hierarchically  to  an  Air  Division 
(SAC)  or  Airlift  Division  (MAC)  ,  which  may  be  linked  hierarchically  to  a 
Numbered  Air  Force  (NAF)  (MAC  5  SAC),  which  is  ultimately  linked 
hierarchically  to  a  MAJCOM  (HQ  USAFE),  which  in  turn  is  linked  to  HQ  USAF 
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AFIRMS  is  a  "push"  system  only.  This  means  that  there  is  upward  reporting  of  data 
at  regular  intervals,  with  no  provision  for  ad-hoc  querying  of  databases  between  sites. 

The  data  accessible  at  AFIRMS  sites  is  at  the  level  of  detail  appropriate  to  the  particular 
command  level.  However,  flexibility  to  increase  the  frequency  of  upward  reporting  cycles 
is  provided  for  exception  reporting  on  a  case-by-case  basis.  Implementation  of  this 
exceptional  reporting  requirement  is  procedural  in  nature,  and  thus  external  to  AFIRMS. 


4.3  Subsystem  Data.  The  HQ  USAFE  site  operates  on  the  following  types  of  data: 

a.  Tasking  Data.  Tasking  data  consists  of;  WMPs,  OPlans/OPORDs,  and  special 
ad-hoc  taskings  from  HQ  USAF. 

b.  Resource  Data.  Resource  data  is  data  collected  and  maintained  by  the  wing 
squadrons  and  consists  of  aircraft  status,  aircrew  status,  fuels  status,  munitions 
status,  and  (for  later  implementation  blocks)  logistics  support  status. 

c.  Theatre  resource  data  such  as  depot  level  fuels  and  munitions  is  maintained  and 
provided  by  depots  and  support  units  via  automated  systems  such  as  CAS, 
CFMS,  etc. 


Figure  4-1.  AFIRMS  Logical  Flow 


1.  DATA  IS  UPDATED  AT  THE  FUNCTIONAL  AREA. 

2.  UPDATED  DATA  IS  PASSED  TO  THE  CENTRAL 
NODE  MODULE. 

3..  THE  CENTRAL  NODE  MODULE  UPDATES  THE 
CENTRAL  DATABASE. 

4.  THE  CENTRAL  NODE  MODULE  SENDS  NOTIFICATION 
OF  DATA  UPDATE  TO  OTHER  FUNCTIONAL  AREAS 
AFFECTED. 

5.  THE  CENTRAL  DATABASE  IS  ALSO  UPDATED  ON  A 
PERIODIC  BASIS  (AT  A  MINIMUM,  EVERY  6  HOURS), 

OR  ON  REQUEST  FROM  THE  MAJCOM  SITE,  WITH 
DATA  THAT  HAS  BEEN  UPDATED  VIA  THE  WINC  LEVEL 
FUNCTIONAL  AREAS  ROLLED  UP  (AGGREGATED) 

AND  TRANSMITTED  TO  THE  MAJCOM. 

6.  ON  A  PERIODIC  BASIS  (AT  A  MINIMUM,  EVERY  6 
HOURS),  OR  ON  REQUEST  FROM  HQ  USAF,  DATA  IS 
TRANSMITTED  TO  THE  AIR  STAFF  LEVEL. 


Figure  4-2.  AFIRMS  MAJCOM  Information  Flow 


a.  The  following  input  data  is  provided  to  the  HQ  USAFE  subsystem: 


(1) 

(2) 

(3) 

(4) 

(5) 

(6) 

(7) 

(8) 

(9) 

(10) 
(ID 


Tasking  Data 

Munitions  Status 

Fuels  Status 

Base  and  Unit  Status 

Aircrew  Status 

Aircraft  Status 

Major  Base  Facility  Status 

Communications  Support  Status 

Transportation  Support  Status 

Maintenance  Support  Status 

Aerial  Port  and  Airfield  Status 


Note:  This  data  is  input  by  HQ  USAFE  for  exercise  purposes,  and  also  for  units  unable  to 
report  this  data  electronically,  e.g.,  deployed  units,  communications  links  down  or 
inoperative  for  various  reasons,  etc. 

b.  Input  Records.  Input  record  nomenclature,  source,  expected  volume,  frequency, 
priority,  degree  of  sensitivity  and  requirement  for  timeliness  are  described  in 
the  AFIRMS  Product  Descriptions  Document.  Interface  specifications 
corresponding  to  input  record  requirements  are  provided  in  Table  3-5  of  this 
subsystem  specification.  The  transaction  header  interface  specification 
detailed  in  Appendix  A  contains  information  to  discriminate  between  input 
records  and  input  data  element  transactions. 

c.  Input  Data  Elements.  Data  elements  for  each  input  record  type  are  described 
in  the  AFIRMS  Database  Specifications  and  the  Data  Requirements  Document. 
Interface  specifications  corresponding  to  input  data  element  requirements  are 
provided  in  Table  3-5  and  Appendix  B  of  this  subsystem  specification.  The 
transaction  header  interface  specification  detailed  in  Appendix  A  contains 
information  to  discriminate  between  input  records  and  input  data  element 
transactions. 


4,3.2  Outputs.  Operational  AFIRMS  outputs  include  reports  and  graphic  readiness 
measurement  displays  as  follows: 

a.  Output  Reports.  All  AFIRMS  output  reports  can  be  displayed  on  the  user's 
terminal  or  printed  as  hardcopy.  There  are  no  requirements  for  preprinted 
forms  for  generation  of  hardcopies. 


Table  4-1  provides  information  concerning  the  format,  complexity,  security 
classification,  and  estimated  daily  volume  and  frequency  of  AFIRMS  output 
reports.  For  response  times  of  these  AFIRMS  output  reports,  please  reference 
Section  2.2.3  of  this  subsystem  specification,  in  which  AFIRMS  query  response 
times  are  provided  for  varying  degrees  of  query  complexity. 

Table  4-2  details  the  primary  and  secondary  functional  area  users  of  AFIRMS 
output  reports.  In  addition,  these  outputs  are  fully  described  in  the  AFIRMS 
Product  Description  series.  (Additional  output  report  requirements  for  each 
MAJCOM  will  be  reviewed  during  the  in-depth  analysis  that  precedes 
implementation  at  that  site.) 

Output  Data  Elements.  Output  data  elements  are  named  in  the  AFIRMS  HQ 
USAFE  Database  Specification  and  described  in  the  AFIRMS  Data 
Requirements  Document;  the  corresponding  interface  specifications  are 
provided  in  Appendix  B  of  this  subsystem  specification. 


Table  4-1 


AFIRMS  OUTPUT  REPORTS 


Screen  Title 

Format 

Estimated 

Daily  Volume 
and  Frequency 

Complexity 

Security 

Classifi¬ 

cation 

Aircraft  8  Mission  Tasking  Details 

Tabular 

1  pg  @1 

Medium 

U-TS* 

Aircraft  Spares  Support  Capability 

Graphic 

1  pg  @20 

Complex 

U-TS* 

Aircraft  Tasking 

Graphic 

1  pg  @12 

Medium 

U-TS* 

Attrition  Statistics 

Tabular 

2  pg  @16 

Simple 

Secret 

Attrition  Trends 

Graphic 

1  pg  @8 

Simple 

Secret 

Base  Fuels  Capability 

Graphic 

1  pg  @20 

Medium 

U-TS* 

Base  Status  (Input) 

T  abular 

8  pg  @16 

Simple 

U-S* 

Base  Status  (Output) 

Graphic 

8  pg  @16 

Simple 

U-S* 

Capability  Perspective 

Graphic 

1  pg  @2 

Complex 

Secret 

Communications  Support  Status 

Graphic 

8  pg  @24 

Simple 

U-S* 

Dollars  to  Readiness  Associations 

Tabular 

3  pg  @8 

Simple 

Unclass 

Dollars  to  Readiness  -  Comparisons 
Dollars  to  Readiness  -  Resource 

Graphic 

1  pg  @8 

Complex 

U-S* 

Perspective 

Graphic 

1  pg  @2 

Complex 

U-S* 

Fuels  Capability 

Graphic 

1  pg  @20 

Medium 

U-TS* 

Individual  Resource  Capability 

Graphic 

1  pg  @12 

Complex 

U-TS* 

Integrated  Capability 

Graphic 

1  pg  @12 

Complex 

U-TS* 

MI  CAP  Forecast 

Tabular 

8  pg  @16 

Medium 

Unclass 

Mission  Area  Tasking 

Graphic 

1  pg  @4 

Medium 

Secret 

Mission  Profile  Definition 

Tabular 

8  pg  @16 

Simple 

U-S* 

Mission  Tasking 

Graphic 

1  pg  @12 

Medium 

U-TS* 

Munitions  Capability 

Graphic 

1  pg  @20 

Medium 

U-TS* 

Munitions  Status 

Munitions  Substitution  Sortie 

Tabular 

8  pg  @48 

Medium 

U-S* 

Capability 

Munitions  Substitution  Sortie 

Graphic 

1  pg  @4 

Complex 

Secret* 

Requirement 

Graphic 

1  pg  @4 

Complex 

Secret* 

OPlan/OPORD  Associations 

Tabular 

3  pg  @8 

Simple 

Unclass 

Order  Assignments 

T  abular 

8  pg  @8 

Simple 

U-S* 

Process  Status 

Tabular 

3  pg  @20 

Simple 

Unclass 

Resource  Reallocation 

Graphic 

1  pg  @8 

Simple 

Secret 

Resource  Unit  Price 

Tabular 

3  pg  @4 

Simple 

Unclass 

Status  Map 

Graphic 

3  pg  @20 

Simple 

U-S* 

Unit  Status  (Input) 

Tabular 

8  pg  @ 

Medium 

U-S* 

Unit  Status  (Output) 

Tabular 

8  pg  @16 

Medium 

U-S* 

War  Mobilization  Plan 

Tabular 

2  pg  @4 

Simple 

Secret 

Wing  Flying  Day 

Tabular 

3  pg  @4 

Simple 

U-S* 

Wing  Operations  Rates 

T  abular 

3  pg  @4 

Simple 

U-S* 

Wing  Resource  Summary 

T  abular 

20  pg  @8 

Medium 

U-S* 

Wing  Resupply  Schedule 

Tabular 

20  pg  @4 

Simple 

U-S* 

*Some  classifications  have  a  range,  i.e.,  U-TS,  meaning  Unclassified  through  Top  Secret 
That  range  normally  results  from  a  variable  tasking  classification  (e.g.,  some  tasks  are 
Unclassified,  some  are  Confidential,  some  are  Secret,  etc.) 
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Note  1 


Note  2 


Depending  on  input  parameters,  some  times  will  increase/decrease 
depending  on  the  amount  of  data  retrieved.  For  example,  requesting 
Munitions  Capability  for  60  days  doubles  the  amount  of  data  and  time 
over  a  30  day  parameter  input  and  increases  the  data  retrieval  time. 

:  1  pg  @  1  denotes  that  the  average  screen  length  (volume)  is  one  page, 

and  it  is  accessed  once  daily. 
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Table  4-2 


AFIRMS  OUTPUT  REPORTS  BY  FUNCTIONAL  AREA  USERS 


Screen  Title  (Implemented) 

Primary  User(s) 

Supporting  User(s) 

Aircraft  Tasking 

BS.  LRC 

DOJN,  DOX,  XPX 

Base  Fuels  Capability 

LRC 

LGSF 

Base  Status  Map 

Reports  Cell 

BS,  LRC 

Base  Status  (I/O) 

Reports  Cell 

BS.  ESRC ,  COMM,  LRC, PRC 

Base  Status  (Output) 

ALCC,  BS,  LRC, 

ESRC ,  COMM,  PRC 

Capability  Perspective 

DOCR 

Dollars  to  Readiness  Associations 

XPX 

LGSF,  LGSS  ,  LG WR 

Dollars  to  Readiness  -  Comparisons 

XPX 

DOJN,  LGSF,  LGSS,  LGWR 

Dollars  to  Readiness  -  Resource 

XPX 

DOJN,  LGSF,  LGSS,  LGWR 

Perspective 

Fuels  Capability 

LRC 

LGSF 

Individual  Resource  Capability 

BS,  LRC 

XPX,  DOX,  DOJN, 

LGSF, LGSS,  LGWR 

Integrated  Capability 

BS,  LRC 

XPX,  DOX,  DOJN,  LGSF, 

LGSS,  LGWR 

Munitions  Capability 

LRC 

XPX,  DOJN 

Munitions  Status 

LRC 

BS 

Mission  Profile  Definition 

DOX,  DOJN 

XPX 

OPlan/OPORD  Associations 

BS,  XPX,  DOX 

DOJN 

Order  Assignments 

BS,  DOJN 

XPX 

Process  Status 

BS,  LRC,  XPX 

Resource  Reallocation 

LRC 

Resource  Unit  Price 

XPX 

LGSF,  LGSS,  LGWR 

Resupply  Schedule 

LRC,  LGX ,  BS 

XPX 

Unit  Staus  (Output) 

BS,  LRC,  ALCC 

Unit  Status  (I/O) 

Reports  Cell 

BS,  LRC,  ALCC,  ESRC, 

COMM 

War  Mobilization  Plan 

DOX,  DOJN,  XPX 

Wing  Flying  Day 

BS,  DOJN 

DOX,  XPX 

Wing  Operations  Rates 

BS.  LRC 

DOX,  LGX 

Wing  Resource  Summary  (0) 

LRC 

Wing  Resource  Summary  (I/O) 

LRC 

Base/Unit  Status  Rollup 

DOCR 

Resource  Rollup 

DOCR 

Run  S-Readiness 

XPX 

Run  S  G  M 

BS,  XPX,  DOX, 

DOJN,  LRC 

Transmit  Base  Status 

DOCR  Reports  Cell 

Transmit  Unit  Status 

DOCR  Reports  Cell 

Transmit  Resource  Status 

DOCR  Reports  Cell 
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Table  4-2 


AFIRMS  OUTPUT  REPORTS  BY  FUNCTIONAL  AREA  USER  (Continued) 


Screen  Title  (Unimplemented) 

Primary  User(s) 

Supporting  User(s) 

Aircraft  Spares  Support  Capability 

LRC 

LOSS 

Attrition  Statistics 

PRC 

BS 

Attrition  Trends 

PRC 

BS 

Communications  Support  Status 

COMM 

Reports  Cell 

Fuel  Status  Map 

LRC 

ALCC,  BS 

Individual  Resource  Capability 

XPX 

LGSF,  LGSS ,  LGWR 

MICAP  Forecast 

LRC 

LGSS 

Mission  Area  Tasking 

Mission  8  Aircraft  Tasking  Detail 

DOJN,  XPX 

Summary 

DOJN,  DOX,  XPX 

BS,  LRC 

Mission  Tasking 

Munitions  Substitution  Sortie 

DOX,  XPX,  DOJN 

BS 

Capability 

Munitions  Substitution  Sortie 

XPX,  DOJN 

LRC 

Requirement 

XPX,  DOJN 

LRC 

ABBREVIATIONS/ACRONYMS/AIR  FORCE  CODES 


ALCC 

BS 

COMM 

DOCR 

DOJN 

DOX 

ESRC 

LGSF 

LOSS 

LGWR 

LGX 

LRC 

PRC 

XPX 


Airlift  Control  Center 
Battle  Staff 

Communications  Readiness  Center 

Command  and  Control  Reports  Division 

Combat  Employment  Capability  Division 

Operations  Plans  (Contingency/Exercise/Special  Plans) 

Engineering  and  Services  Readiness  Center 

Energy  Management 

Supply  Management 

Munitions  Requirements  Division 

Logistics  Plans 

Logistics  Readiness  Center 

Personnel  Readiness  Center 

Operations  Plans 
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4.3.3  Database  Description.  For  detailed  AFIRMS  database  requirements,  refer  to  the 
A  F  IK  Mb  HQ  LSAFt  DataBase  Specification. 


a.  Database  Identification.  The  label  by  which  the  HQ  L'SAFE  database  is 
uniquely  identified  is  "HQU SAFEDB."  The  HQ  USAFE  subsystem  maintains 
databases  as  follows: 

(1)  Real:  This  database  contains  peacetime  and  crisis  tasking,  and  other 
day-to-day  operational  data.  .* 

(2)  What  If:  This  physical  database  is  comprised  of  three  types  of  logical 
databases: 

(a)  Exercise  -  This  database  contains  data  which  provides  a 

simulation  of  an  actual  crisis. 

(b)  Ad-Hoc  What  If  -  This  database  contains  data  which  provides  a 

simulation  of  a  hypothetical  crisis  or  situation. 

(c)  Historical  -  This  database  contains  data  which  provides  a 

historical  view  of  the  real,  exercise,  or  ad-hoc 
what  if  databases. 

b.  Storage.  The  master  file(s)  containing  the  HQ  USAFE  database  are  stored 
on-line  on  mass-storage  disk  devices  and  off-line  on  magnetic  tape  and 
formatted  floppy/microfloppy  disk. 

c.  Database  Query  Capabilities.  The  design  of  the  AFIRMS  database  supports  the 
requirements  for  an  interactive  query  capability  accessing  current  and/or 
what-if  data  for  the  above-named  databases.  Historical  data  resides  primarily 
on  off-line  media  and  is  copied  to  on-line  media  on  an  "as-needed"  basis. 

(  1)  Ad-Hoc  Querying.  Selected  users  may  execute  ad  hoc  queries  against  any 
on-line  databases  to  which  they  are  permitted  access.  Ad  hoc  querying  is 
constrained  by  AFIRMS  security  and  control  requirements.  This 
capability  is  limited  to  databases  located  at  the  functional  area  and  the 
central  location  within  a  site.  Controls  within  the  DBMS  and  security 
software  are  used  to  limit  access  to  both  the  functional  area  and  central 
database  on  a  user-by-user  basis. 

Ad  hoc  query  access  is  provided  by  the  AFIRMS  executive.  The  user  has 
the  ability  to  interactively  query  the  database  via  an  "English-like" 
AFIRMS  query  utility.  The  user  does  not  have  the  ability  to  update  any 
data  while  in  this  mode.  Ad  hoc  queries  are  limited  to  current  or  crisis 
mode  data  only.  When  data  is  requested,  if  it  is  not  present  in  the  local 
functional  area  database,  the  request  is  transmitted  to  the  central  node. 
The  request  is  then  processed  at  the  central  node  and  the  results  returned 
to  the  requesting  functional  area  for  display.  There  is  no  capability  for 
ad-hoc  querying  across  sites  within  AFIRMS. 


4-y 


334  11 


(2)  What-if  Capability.  A  what-if  capability  exists  in  AFIRMS  to  enable 
certain  users  to  input  hypothetical  tasking,  resource,  or  operations 
scenarios  to  better  predict  future  readiness  capability.  The  data  is  input 
into  the  local  database  through  a  highly  structured  AFIRMS  environment. 
The  what-if  capability  of  AFIRMS  directly  affects  the  amount  of  data 
redundancy  necessary  at  each  site  and,  accordingly,  the  amount  of 
physical  storage  capacity  necessary  to  handle  it.  What-if  data  storage 
needs  vary  according  to  the  level  in  the  command  structure  and  the 
functional  users'  what-if  exercise  needs. 

d.  Database  Backup,  Restoration,  and  Archiving.  Backup  of  the  database  to 
off-line  media  occurs  on  a  daily,  weekly,  monthly,  and  yearly  basis;  each  backup 
is  maintained  for  a  different  length  of  time: 

(1)  Daily  Database  Backups.  Daily  backups  are  maintained  for  five  working 
days. 

(2)  Weekly  Database  Backups.  Weekly  backups  are  maintained  for  five  weeks. 

(3)  Monthly  Database  Backups.  Monthly  backups  are  maintained  for  12 
months. 

(4)  Yearly  Database  Backups.  Yearly  backups  are  maintained  for  five  years. 

Restoration  occurs  in  the  event  that  data  in  the  database  has  been  lost  or 
damaged.  Whenever  a  transaction  occurs  in  the  local  database,  it  will  be  logged 
to  a  journal  file  for  use  in  the  event  restoration  is  needed.  Restoration  consists 
of  reloading  the  latest  copy  of  the  database  from  off-line  media,  if  necessary, 
and  applying  the  journal  log  file  to  it. 

Archiving  of  data  to  tape  or  disk  is  accomplished  as  required  by  AFIRMS  users. 

e.  Database  Size.  It  is  estimated  that  the  size  of  all  the  files  contained  in  the  HQ 
L'SAFE  database  is  a  total  of  approximately  74  megabytes. 

f.  Database  Elements.  AFIRMS  HQ  USAFE  database  elements  are  described  in 
the  AFIRMS  HQ  ESAFE  Database  Specification  and  Data  Requirements 
Document. 

4.4  Program  Description.  This  subsystem  specification  is  to  contain,  as  annexes,  C-level 
program  specifications  which  detail  specific  requirements  for  the  subsystem  functional 
products.  The  HQ  L'SAFE  subsystem  consists  of  the  following  programs  in  addition  to 
systems  software: 


Screen/Process  Title 

Aircraft  A  Mission  Tasking  Details 
Aircraft  Spares  Support  Capability 
Aircraft  Tasking 
Attrition  Statistics 
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Attrition  Trends 
Base  Fuels  Capability 
Base  Status  (Input) 

Base  Status  (Output) 

Base  Status  Report 

Base/L’nit  Status  Rollup 

Capability  Perspective 

Communications  Support  Status 

Dollars  to  Readiness  Associations 

Dollars  to  Readiness  -  Comparisons 

Dollars  to  Readiness  -  Resource  Perspective 

Flying  Schedule 

Fuels  Capability 

Individual  Resource  Capability 

Integrated  Capability 

MICAP  Forecast 

Mission  Area  Tasking 

Mission  Profile  Definition 

Mission  Tasking 

Munitions  Capability 

Munitions  Capability 

Munitions  Status 

Munitions  Substitution  Sortie  Capability 

Munitions  Substitution  Sortie  Requirement 

OPlan/OPORD  Associations 

Order  Assignments 

Post  Base  Status 

Post  Resource  Updates 

Post  Unit  Status 

Process  Status 

Resource  Reallocation 

Resource  Status  Rollup 

Resource  Unit  Price 

Run  Dollars  to  Readiness  Model 

Run  Sortie  Generation  Model  (SGM) 

SGM  Associations 
Status  Map 
Transmit  Base  Status 
Transmit  Resource  Status 
Transmit  Unit  Status 
Unit  Status  (Input) 

Unit  Status  (Output) 

War  Mobilization  Plan 
Wing  Flying  Day 
Wing  Operations  Rates 
Wing  Resupply  Schedule 


For  detailed  descriptions  of  these  products,  refer  to  the  AFIRMS  Product  Descriptions 
Index  and  Document. 


APPENDIX  A.  INTRASITE  TRANSACTION  HEADER 


Field  Name 

TRANSJD 

TR  A  N  S_M  SG_L  E  N 

REQ_REP_FLAG 

JOB_TYPE 

SRCJNODEJD 

SRCJERMJD 

SRC_L'SER_N  A  ME 

DST  NODE  ID 
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Field  Description 

a.  Transaction  identifier. 

b.  Each  terminal  has  its  own  IDs. 

c.  The  legal  values  are  1 — >65535.  After  65535,  it  reverts  back  to  1. 

a.  Transaction  message  length. 

b.  The  length  is  the  sum  of  the  transaction  header  plus  data  length. 

c.  The  legal  values  are  S5— >8192. 

a.  Request/Reply  flag. 

b.  User  interactive  display  software  always  sends  requests.  The  host 
always  sends  replies  in  response  to  the  request  as  long  as  the 
transaction  was  not  submitted  as  a  batch  job.  The  host 
occasionally  sends  unsolicited  requests  to  the  CGC  (i.e.,  update 
messages).  It  does  not  expect  a  reply. 

c.  The  legal  values  are  "Q"  for  request  and  "P"  for  reply. 

a.  Interactive/Batch/Network  flag. 

b.  All  jobs  must  run  interactively  if  they  expect  a  product  screen 
display.  Otherwise,  they  can  be  run  as  batch.  Note:  batch  jobs 
never  send  back  replies.  Their  status  can  be  monitored  through 
the  batch  monitor  screen. 

c.  The  legal  values  are  "I"  for  interactive,  "B"  for  batch,  and  "N"  for 
network. 

a.  Source  node  ID. 

b.  This  is  the  node  ID  of  the  requestor. 

a.  Source  terminal  ID. 

b.  This  is  the  terminal  ID  of  the  requestor. 

c.  The  legal  values  are  local  site  dependent.  Note:  the  value  1111  is 
reserved  for  host  generated  transactions  (i.e.,  unsolicated  update 
messages). 

a.  Source  username. 

b.  This  is  the  username  of  the  requestor. 

c.  The  legal  values  are  site  dependent.  They  must  match  the 
username  used  for  logging  into  the  host. 

a.  Destination  node  ID. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as 
the  SRCJNODEJD  for  the  local  requests  that  require  a  reply.  In 
general,  it  is  always  the  nodo  ID  of  where  the  transaction  is 
destined.  It  differs  from  the  SRCJNODEJD  only  for  network 
messages. 
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Field  Name 


Field  Description 


DST_TERM_1D  a.  Destination  terminal  ID. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as  the 
SRC_TERM_ID  for  the  requests  that  require  a  reply.  In  general,  it 
is  the  terminal  ID  of  where  the  transaction  is  destined.  It  differs 
only  for  network  messages. 

c.  The  legal  values  are  remote  site  dependent. 

DST_LSER_.N AME  a.  Destination  username. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as  the 
SRC_USER_N  AME  for  the  requests  that  require  a  reply.  In 
general,  it  is  always  the  username  of  where  the  transaction  is 
destined. 

c.  The  legal  values  are  site  dependent.  They  must  match  the 
username  used  for  logging  into  the  host  for  local  transactions. 

For  network,  transactions,  the  username  '‘♦ROLLUP*11  is  reserved. 

EXP_DAT_TIM  a.  Transaction  expiration  date/time. 

b.  There  are  four  subfields: 

1.  Expiration  year 

b.  The  legal  values  are  0—  >  99. 

2.  Expiration  day 

b.  The  legal  values  are  1  —  >366.  Note:  366  is  only  valid  for 
leap  years. 

3.  Expiration  hour 

b.  The  legal  values  are  0—  >23. 

L.  Expiration  minute 

b.  The  legal  values  are  0  —  >  59. 

MOD_REQ_ID  a.  Module  request  ID. 

b.  This  field  is  looked  at  only  by  the  transaction  routing  mechanism 
to  determine  whether  the  transaction  is  destined  for  the  database 
server  or  somewhere  else. 

c.  The  legal  values  are  1  — >  2.  Their  meanings  are  as  follows: 

1  =  forward  transaction  to  the  database  router 

2  =  AFIRMS  service  request 

FL\C_REQJD  a.  Function  request  ID. 

b.  This  field  is  looked  at  by  the  transaction  routing  mechanism  only 
when  MOD_REQJD  =  2.  It  signifies  what  AFIRMS  service  to 
perform.  Currently,  the  only  service  is  to  log  off  the  user. 

c.  The  legal  values  are  1—  >10.  Their  meanings  (when  MOD_REQ 
I D  =  1 )  are  as  follows: 

1  =  organize  records  (send  transaction  /f2) 

2  =  update  record 

3  =  insert  record 

4  =  delete  record 

5  =  logoff  Database 

6  =  edit  info  (send  transaction  if  [) 

7  =  insert  continuation  record 
3  =  delete  continuation  record 
9  =  log  invalid  batch  job 

10  =  transmit  rollup  status 
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Field  Name 


MSG  PRIG 


MSG  STAT 


MSG  SEG  CUR 


MSG  SEG  TOT 


Field  Description 

a.  Message  priority. 

b.  This  field  is  used  by  the  process  controller  to  put  each  transaction 
it  receives  into  the  appropriate  priority  mailbox  (i.e.,  queue). 

(1)  The  transaction  router  uses  it  as  a  consistency  check  to  make 
sure  the  transaction  is  sent  to  the  right  mailbox,  and 

(2)  to  set  the  priority  of  the  Database  server  that  will  be 
processing  that  transaction,  and 

(3)  The  Database  server  uses  it  to  determine  to  which  priority 
mailbox  it  should  forward  replies. 

c.  The  legal  values  are  1  for  low  priority,  5  for  medium  priority,  and 
9  for  high  priority. 

a.  Message  status. 

b.  This  field  is  used  for  returning  the  status  of  a  user's  request. 

c.  The  legal  values  are  any  32-bit  number.  Note:  MSG_STAT  must 
be  initially  set  to  0  in  the  original  request. 

a.  Message  number  current. 

b.  This  field  is  the  current  message  segment  number.  It  is  always  1 
unless  there  is  a  multi-part  transaction  (i.e.,  one  that  must  split 
because  it  is  too  large  for  a  single  buffer). 

c.  The  legal  values  are  1  —>255. 

a.  Message  number  total. 

b.  The  legal  values  are  1  —>255. 


APPENDIX  B 

B.l  Data  Interface  Specification  (GENEDIT) 


Oi 


Date:  31-May-1985 


Current 

Clcest 

Latest 

As-of- 

Screen 

Time-of- 

screen 

screen 

status 

Classification 

day  DTG 

value  DTG 

value  DTG 

DTG  flag 

As-of-status 

DTG 


//  of 
records 


//  of 

subtitles 


Repeats^//  of  subtitles)times 


Subtitle 


•Repeats  0  of  records)  times 


//  of  continuation 
lines 


Repeats  for  all  fields  in  a  recorc 


■  Repeats  0  of  continuation  lines)  times 
—  Repeats  for  all  fields  in  a  continuation  line 


Field  Length 


Field  Name 

Screen  classification 

Current  time-of-day  DTG 

Oldest  screen  value  DTG 

Latest  screen  value  DTG 

As-of-status  DTG  flag 

As-of-status  DTG 

It  of  subtitles 

Subtitle 

//  of  records 

//  of  continuation  lines 

Length  of  field 

Field 


Note:  (1)  Each  field  whose  length  is  represents  a  variable  length  field.  The  fields 
are  preceded  with  a  2-byte  length  descriptor. 

(2)  The  number  of  fields  in  a  record  or  a  continuation  line  is  screen  specific. 
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as 
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B.2  Data  Interface  Specification  (CAPABILITY) 


Date:  3 1-May- 1 985 


Screen 

Classification 


As-of-status 

DTG 


Current 
Time-of- 
day  DTG 


it  of 

subtitles 


Oldest  Latest 
screen  screen 
value  DTG 


As-of- 
status 
value  DTG 


DTG  flag 


Repeats \tt  of  subtitles>  times 


Subtitle 


it  of  #  of 

taskings  days 

—  Repeats <//  of  taskings>  times 

r- Repeats  <// of  days>  times 


T  asked 
item  name 


Tasked 

amount 


Repeats  <Jt  of  capable  lines  per  tasking> 

/ — Repeats^//  of  days>times 


//  of 
capable 
lines  per 
tasking 


Capable 


Capable 

amount 


Field  Name  Field  Length 

Screen  classification  l 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG  ? 

It  of  subtitles  2 

Subtitle 

//  of  taskings  3 

it  of  days  3 

Tasked  item  name  2 

Tasked  amount 

it  of  capable  lines  per  tasking  ? 

Capable  item  name 

Capable  amount  9 

Note:  Each  field  whose  length  is  represents  a  variable  length  field.  The  fields  are 

preceded  with  a  2-byte  length  descriptor. 
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B.3  Data  Interface  Specification  (MAP)  Date:  31-May-1985 


The  AREA-C  buffer  layout  for  MAP  SCREENS  is  as  follows: 


Current 

Oldest 

Latest 

As-of- 

Screen 

Time-of- 

screen 

screen 

status 

Classification 

dav  DTG 

value  DTG 

value  DTG 

DTG  flag 

i - Repeats^//  of  subtitles>times 


As-of-status 

It  of 

DTG 

subtitles 

Subtitle 


It  of 
records 


Repeats^#  of  records>times 
I —  Repeats  for  the  It  of  fields  in  this  screen's  recora. 


Field  Name 


Field  Length 


Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG  ? 

It  of  subtitles  2 

Length  of  subtitles  2 

Subtitle  ? 

tt  of  records  3 

Length  of  field  2 

Field  ? 


Note: 


(1) 

(2) 


Each  field  whose  length  is  represents  a  variable  length  field, 
are  preceded  with  a  2-byte  length  descriptor. 

The  number  of  fields  in  a  record  is  screen  specific. 


The  fields 
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B.4  Data  Interface  Specification  (FORECASTS) 


Date:  31-May-1985 


The  AREA-C  buffer  layout  for  AVAILABILITY  FORECAST  SCREENS  is  as  follows: 


Historical 

It  at 

It  of 

it  of 

Expenditure 

average 

historical 

Critical 

forecast 

offbase 

rate 

flag 

days  avg. 

level 

days 

locations 

_ Repeats<//  of  historical  days  plot)>times 


it  of 

it  of 

days  to 

days 

critical 

remaining 

//  of 

historical 
days  plot 


Amount 
on  hand 
(day  //X) 


Field  Name _  Field  Length 


Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG 

It  of  subtitles  2 

Subtitle  ? 

Expenditure  rate  2 

Historical  average  flag  1 

it  of  historical  days  avg.  3 

Critical  level 

It  of  forecast  days  3 

It  of  offbase  locations  1 

it  of  historical  days  plot  3 

Amount  on-hand  (day  // 1  -n) 
it  of  days  to  critical  3 

It  of  days  remaining  3 


ore:  Each  field  whose  length  is  "2",  represents  a  variable  length  field.  These  fields  are 

preceded  by  a  2-byte  length  descriptor  field. 
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B.5  Data  Interface  Specification  (BAR  CHART  WITH  LINES)  Date:  31 -May- 1985 


The  AREA-C  buffer  layout  for  BAR  CHART  WITH  LINE  SCREENS  is  as  follows: 


Screen 

classification 


Current 

Oldest 

Latest 

Time-of- 

screen 

screen 

Task  ID 

day  DTG 

value  DTG 

value  DTG 

DTF  flag 

Task-ID 

it  of 

DTG 

subtitles 

Repeats<//  of  subtitles>times 


Subtitle 


Repeats  <//  of  bars^times 


Bottom 

Top 

bar 

bar 

height 

height 

Field  Name 


Repeats  <//  of  bars>times 

Line 

height 

Field  Length 


Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

Task-ID  DTG  flag  1 

Task-ID  DTG  ? 

it  of  subtitles  2 

Subtitle  ? 

it  of  bars  3 

Bottom  bar  height  2 

Top  bar  height  2 

Line  height  ? 

:  Each  field  whose  length  is  "2",  represents  a  variable  length  field.  Only  these 
fields  shall  be  preceded  by  a  2-byte  length  descriptor  field. 


Date:  31-May-1984 


The  AREA-C  buffer  layout  for  BAR  CHART  SCREENS  is  as  follows: 


//  of 
bars 


Repeats  (if  of  bars)  times 


Label 

Front 

Rear 

Front 

Rear 

for 

bar 

bar 

bar 

bar 

bar 

value 

value 

color 

color 

Field  Name 

//  of  bars 
Label  for  bar 
Front  bar  value 
Rear  bar  value 
Front  bar  color 
Rear  bar  color 


Field  Length 
3 

n 

o 

O 

3 

3 


Note: 


Each  field  whose  length  is  represents  a  variable  length  field, 
preceded  by  a  2-bvte  length  descriptor  field. 


These  fields 


3  *  b  3 1 


